Updates:
Welcome to the second of this 2-part blog series on the concept of FUE (Full Use Equivalent) and what you can do to plan, monitor and influence the outcome of this metric.
If you are unsure what an FUE is, then I suggest you start by reading part 1- Did you say FUE? A definition.
As I said in the introduction of the previous blog, I will try to cover different points that may occur at different times of your journey in implementing and using SAP S/4HANA Cloud. I also hope that in the thick of the information covered in part 1, one important detail/object name did not go unnoticed, and that, is the Business Role(s) – that are assigned to the business user(s). Much of this blog will focus on this object as so much hinges on or is connected to it.
As ever, planning is key. No one wanders into a software implementation wishing things will go well!
Be strategic and try to get as much information about the implementation that you are about to embark on beforehand, but also try to understand where your company wants to go in 3,4,5 years so that you can incorporate as many possible influencing elements as early as possible, rather than later when it happens, and at the same time, possibly avoid unnecessary rework and or delays (and hence cost and efforts).
For example, you are planning to expand your business. E.g., you have classically been operating as a wholesale company, but you are in the short-term going to start to venture into manufacturing a line of products yourself. Or, you are going to acquire an additional, similar business in another country, that is running its own software for now but you plan to migrate them into your SAP S/4HANA Cloud system in the medium term.
Some of the questions you might ask yourself in light of these scenarios might be:
Hopefully, as we develop this blog, we will be able to provide answers to these questions.
What is a business role going to represent to you?
Since the business role is going to be so important, it might serve to have an idea of what a role will be for you. There is probably no ‘one size fits all’ answer to this question, but I would recommend that you keep it as modular as possible so that as employees evolve in the organization, you are only required to take away the role(s) from their user master that they no longer need, and add the new roles that they need to complete their duties as part of their new job (e.g. A person changes position from Production Operator to Production Supervisor). Think of interchangeable Lego blocks.
Also, as you will have done your homework, you will have created your own roles and correctly classified each role (i.e determined each role to be Self-service, Advanced, etc…), that way as the role assignments to users change, you are also able to keep track of the Use Type classification changes of your users, and thus of your FUE consumption.
As you design your roles, maybe one way to proceed might be to think of ‘Personas’ to help you structure your roles. For example, a persona could be an ‘Accounts Payable Accountant’. As you ask yourself, what does this AP accountant Persona do business-wise and what do they need system-wise in order to be able to do their job. It might be good to carry out this exercise in concert with representatives of your HR team, of the business team (e.g., the Accounts Payable department), and the IT team (or the team that will create and maintain the roles). If this does not already exist in your organization, it will help to strengthen inter-departmental collaboration and benefit processes such as hiring employees, on/off-boarding of users…. HR can check the job description (duties and responsibilities) they have for this position (it might also be an opportunity to help them craft the job positions you will advertise for those manufacturing roles!), for the business to voice the kind of access that persona will need in the system, and thus providing the input to the IT team to create or amend the appropriate role(s).
An output of this meeting might be a recapitulative table that clearly identifies what this persona needs in terms of system capabilities first and of features second, in terms of processing (transactional), in terms of reporting (reports and analytics), and maybe also approval rights (approval of invoices). You should then have enough information to make decisions with respect to how the business roles will be structured. An example is shown below.
For a given Persona, we worked out the system capabilities that were required, assigned the features (transactions, apps) that were needed within that capability, and then clubbed together those features based on what our criterias might have been into individual, logical roles. We then assigned four roles to our AP Accountant Persona. Please also note that as illustrated above, some roles may be valid across a number of positions/personas in your organization. The use case here is that the ‘Master Data Manager’ role is needed for both the AP Accountant Persona as well as the Master Data Steward Persona.
As the system user requirements are identical, there is no need to create 2 identical roles! The immediate advantage we have here is that if at some point the ‘Master Data Manager’ role needs to evolve, we change the role Once, and both the AP Accountant and Master Data Steward Personas would benefit from this change.
As I said earlier on, the way you design your roles is not a one size fits all, so I would not like you to think that the above method, is a must-follow recommendation. The figure below illustrates another way we could have proceeded, namely that we could have grouped together all the required system capabilities into One role. I am sure that there will be some use cases where this route also makes sense. However taking the example above, if the ‘Master Data’ capabilities of our enterprise needed to evolve, we would need to perform the change twice. Once in the AP accountant Persona, and Once in the Master Data Steward Persona.
You could also structure your roles, using a logical combination of both methods.
Let’s take the following requirements/assumptions into account and see how they will affect your roles structuring design choices.
So, on the basis of that information, can you already mentally work out how many roles you are going to need?
Let’s see how these requirement affects our workflow when creating roles for these personas.
Because we need to distinguish between the ability to create/change vs display, to abide by this requirement, we would need to have 2 different roles
However, the next requirement we need to abide by, is that each persona can only access the data in their own company code. We have two company codes to deal with, meaning that we need to be able to create/change and display in company code North, and the same applies to company code South.
So, to comply with these requirements we would need 4 roles, as shown below.
In the example above, we have in the same role combined the transactional and organizational aspects. This is one way of doing it. To emphasize, again, that this is not a must-follow guidance that I am offering here, we could also have created one role containing only the transactional access (Create/Change Asset Master) and another transactional role containing the Display Asset Master access, and then 2 additional organizational roles containing only the organizational accesses: one for company code North and one for company code South.
If we again put this in relation to the FUE concept, the SDG/SUD indicates that Display rights are covered by the Use Type Self-service. This means that the user that has the Create/Change role would be classified as an Advanced Use Type and the user that has the Display only role would be classified as a Self-service Use Type – even though they both access the same app. Again, something to consider in order to keep your FUE consumption in check.
Irrespective of how you decide to structure your roles, you will end up with a number of roles, and it will be very valuable for you to be able to identify on the basis of a naming convention what a given role represents rather than having to open the role to find out. Again, planning comes into play here. Say you go live with one company code, and you create a role ‘AP Accountant’. You then add a new company code, but as before you need to segregate this role by company code. What are you going to do? Delete the previous AP Accountant role, and create 2 new roles, ‘AP Accountant North’ and ‘AP Accountant South’? Clean option. Or are you going to keep the old role and create a new one, so now you would have a role named ‘AP Accountant, and one named ‘AP Accountant South’. Not a clean option and a diverging naming convention.
I would recommend that you work on and internally publish a naming convention to structure the code of your roles which will be valuable in terms of structuring, identification, maintenance and assignments to users and contribute toward increasing your enterprise architecture maturity if it needed to be.
An example of this is shown below where we have in Excel laid out the various parts that make up the code of the business role, and then simply used the CONCATENATION function to put it all together. In our case, we have in the codification of our roles used a code for the role, the country that applies, the organizational ID code, and the kind of access this role provides (Create vs Display). The first column represents the concatenated code of the role, as we will use it in the system.
A side benefit of planning here is that you can also make sure that the length of your role codes does not exceed the maximum length permitted in the system!
We have also for information purposes added the HR name of the role and the Use Type classification of the role and we will see later why this could be helpful for our planning purposes.
The above is just an example, I would certainly encourage you to determine your own codification/naming convention rules, based on criteria that makes sense to you. I would also like to bring your attention to two accelerators that are available, from the SAP Activate roadmap, that include many recommendations for roles, as well as Fiori Spaces and Pages.
As you probably know, SAP FIORI Spaces and Pages is SAP’s future direction for the user experience (UX) when interacting with SAP S/4HANA Cloud.
Without wanting to go into too much detail on this – as not the point of the blog – Fiori Spaces and Pages provide for a great UX when Using SAP S/4HANA Cloud. In a nutshell, it allows you to design how the features a user has access to will be presented to them. You can leverage SAP standard Spaces and Pages, but you can also design your own. I however mention this, as your SAP Fiori Spaces and Pages design hinges, once again on your business roles.
The image below articulates how the business roles relate to the Fiori Spaces and Pages design, and ultimately what the user will see when he logs on and thus his experience of the system, which you want to be great, to ensure adoption of the solution.
If you would like to know more about Fiori Spaces and Pages then I would recommend you read the blogs written by my colleagues Jocely Dart, Sylvia Strack and George Yu as a starting point:
So, in addition to designing your roles to ensure that your users will have access to all the features they need to perform their duties, you also need to design the way in which they will consume SAP S/4HANA cloud.
In this case, whilst the Spaces and Pages have nothing to do with FUEs, I mention them, because you want to be strategic and plan for them - you do not want to think about this aspect in a manner that is disconnected from your roles design after you have gone live. This is in an effort to avoid rework later on, but also think holistically not just about what a user needs to do his job, but structure it in such a way that once in the system everything will make sense to them and make their workflow that much more efficient. For example, are you going to segregate your procurement features, from your inventory, accounting …. features, or neatly group together the individual tiles that would allow one to create a purchase order, receipt it, enter the invoice, pay the supplier. Takeaway: think about the user experience.
You have by now decided on the structure and built your business roles, you have identified your personas and know which roles each persona requires, and you know the users that will access the SAP S/4HANA Cloud system and their personas. It is now time to orchestrate all these pieces and ready the information that you will pass on to the person tasked with creating these users in the system. At the same time, if you did your work well, you will be able to off-system, and assess a realistic FUE position.
All the information we have put together in this sheet is:
Having this FUE number on day one of your go-live is going to be of immense value in your relationship with your CSP (Customer Success Partner), in your ability to have valuable conversations with them on the basis of this factual information, and not execute programs of work because ‘you think are under using your FUEs’. The adage you can’t improve what you can’t measure applies here as well.
The fruits of your hard work have paid off, you are live. You might be inclined to think that you are done. You are not. What you do not want, is to let all the efforts you have put in till now go to waste. So here are some pointers that I would encourage you to consider.
I would encourage you to set up a small, dedicated team of people that are responsible for the maintenance and assignment of roles to users, to make sure that every role change is controlled, compliant and every change measured.
You contracted 100 FUEs and based on your hard work above, you have deduced that you are using 100 FUEs. Or are you? You have to remember that creating a user and assigning roles to them and consuming your FUE entitlements, does not mean that they are actually using the system! You should monitor this, not to police but to take corrective actions if need be.
As an example, you could check to see which users have not logged on to the system in the last 4 weeks. The reasons for this could be varied.
In SAP S/4HANA Cloud, public edition, for example, you have a dashboard in the ‘IAM Key Figures’ app, that will give you this information.
Each element of the bar chart can be selected to drill down to the list of users represented by that data element.
Despite your best efforts to build appropriate roles, it could be that some erroneous decisions were made when you crafted your roles and adjustments need to be made. For example, maybe you thought that ‘Sales Representatives’ were going to require the ability to create ‘Customer Business Partners’.
You should then check if sales representatives are actually using this capability. If yes, then great, but if not, and if the reason is due to an erroneous decision, then adjust your roles accordingly. Doing this might also affect the Use Type of your roles by downgrading a role from ‘Advanced’ to ‘Core’ for example, which will then reduce your FUE consumption, and allow you to re-allocate it to someone else that requires a more expansive access to the system!
Of course, it would be a mammoth task to perform this exercise for each and every role and each and every app, so you will probably want to be selective. Also, as it may be that you will not have a nice report that gives you exactly this information, I would propose as a workaround that you look at the creation statistics, i.e. use a business partner CDS (or app Manage Business Partner) to check if a given user has created any business partners.
In SAP S/4HANA Cloud, private edition, you could additionally also look into transaction SUIM to see if it yields information that is applicable to your investigations.
On and off-boarding users reflect the comings and goings of your employees. For me the off-boarding is maybe more important than on-boarding. Only recently, did a CSP colleague ask for my help with their customer, because their super user had left the organization and they did not know what to do with that person’s user master in the system, nor did they know what they need to do with it. So, to accompany the process of a departing colleague, below are some of the items that you should have on the departure checklist, before and after they leave.
Before:
After:
I hope you have found this blog useful. That it has demystified what an FUE is, how you calculate it, and that the blog highlighted areas that you had not thought to include in your project planning or implementation.
If you have any follow-up questions, then please do not hesitate to ask them below. However, if you have any questions that are of a commercial nature, they will not be answered here, and I would encourage you to engage with your CSP or usual SAP Commercial contact.
- Added references to SAP Activate Role naming convention recommendations
Welcome to the second of this 2-part blog series on the concept of FUE (Full Use Equivalent) and what you can do to plan, monitor and influence the outcome of this metric.
If you are unsure what an FUE is, then I suggest you start by reading part 1- Did you say FUE? A definition.
As I said in the introduction of the previous blog, I will try to cover different points that may occur at different times of your journey in implementing and using SAP S/4HANA Cloud. I also hope that in the thick of the information covered in part 1, one important detail/object name did not go unnoticed, and that, is the Business Role(s) – that are assigned to the business user(s). Much of this blog will focus on this object as so much hinges on or is connected to it.
Before the implementation.
As ever, planning is key. No one wanders into a software implementation wishing things will go well!
Think Strategically.
Be strategic and try to get as much information about the implementation that you are about to embark on beforehand, but also try to understand where your company wants to go in 3,4,5 years so that you can incorporate as many possible influencing elements as early as possible, rather than later when it happens, and at the same time, possibly avoid unnecessary rework and or delays (and hence cost and efforts).
For example, you are planning to expand your business. E.g., you have classically been operating as a wholesale company, but you are in the short-term going to start to venture into manufacturing a line of products yourself. Or, you are going to acquire an additional, similar business in another country, that is running its own software for now but you plan to migrate them into your SAP S/4HANA Cloud system in the medium term.
Some of the questions you might ask yourself in light of these scenarios might be:
- How many additional users will we need to cater for in X months when we bring this new business online (FUE impact!)?
- How will this influence our business roles design? Will we need new ones (for the manufacturing scenario, most definitely),
- How will we map the tasks and responsibilities that a person has to perform with respect to their position and duties with the capabilities they need to have in the system to do their job? (i.e.: Who will decide that an AP accountant needs to be able to have access to the Supplier Invoice app?),
- Will the role design (in terms of system capabilities) of an AP accountant be the same in all companies? Or will there be specifics (e.g. in country X there is a specific tax handling procedure)?
- Will some people be able to view data across all organizational levels (E.g.: Company codes), or will everyone be restricted to the data in their own company only?
- Will some users be able to access a capability in ‘Display’ mode only, or will everyone be able to create or change data (FUE impact!)?
- Will the users in country X use the system in English, or will they require their own specific language?
- …
Hopefully, as we develop this blog, we will be able to provide answers to these questions.
Moving into the implementation.
What is a business role going to represent to you?
Since the business role is going to be so important, it might serve to have an idea of what a role will be for you. There is probably no ‘one size fits all’ answer to this question, but I would recommend that you keep it as modular as possible so that as employees evolve in the organization, you are only required to take away the role(s) from their user master that they no longer need, and add the new roles that they need to complete their duties as part of their new job (e.g. A person changes position from Production Operator to Production Supervisor). Think of interchangeable Lego blocks.
Also, as you will have done your homework, you will have created your own roles and correctly classified each role (i.e determined each role to be Self-service, Advanced, etc…), that way as the role assignments to users change, you are also able to keep track of the Use Type classification changes of your users, and thus of your FUE consumption.
As you design your roles, maybe one way to proceed might be to think of ‘Personas’ to help you structure your roles. For example, a persona could be an ‘Accounts Payable Accountant’. As you ask yourself, what does this AP accountant Persona do business-wise and what do they need system-wise in order to be able to do their job. It might be good to carry out this exercise in concert with representatives of your HR team, of the business team (e.g., the Accounts Payable department), and the IT team (or the team that will create and maintain the roles). If this does not already exist in your organization, it will help to strengthen inter-departmental collaboration and benefit processes such as hiring employees, on/off-boarding of users…. HR can check the job description (duties and responsibilities) they have for this position (it might also be an opportunity to help them craft the job positions you will advertise for those manufacturing roles!), for the business to voice the kind of access that persona will need in the system, and thus providing the input to the IT team to create or amend the appropriate role(s).
An output of this meeting might be a recapitulative table that clearly identifies what this persona needs in terms of system capabilities first and of features second, in terms of processing (transactional), in terms of reporting (reports and analytics), and maybe also approval rights (approval of invoices). You should then have enough information to make decisions with respect to how the business roles will be structured. An example is shown below.
Example planning of Personas, capabilities, features, and roles structure
For a given Persona, we worked out the system capabilities that were required, assigned the features (transactions, apps) that were needed within that capability, and then clubbed together those features based on what our criterias might have been into individual, logical roles. We then assigned four roles to our AP Accountant Persona. Please also note that as illustrated above, some roles may be valid across a number of positions/personas in your organization. The use case here is that the ‘Master Data Manager’ role is needed for both the AP Accountant Persona as well as the Master Data Steward Persona.
As the system user requirements are identical, there is no need to create 2 identical roles! The immediate advantage we have here is that if at some point the ‘Master Data Manager’ role needs to evolve, we change the role Once, and both the AP Accountant and Master Data Steward Personas would benefit from this change.
As I said earlier on, the way you design your roles is not a one size fits all, so I would not like you to think that the above method, is a must-follow recommendation. The figure below illustrates another way we could have proceeded, namely that we could have grouped together all the required system capabilities into One role. I am sure that there will be some use cases where this route also makes sense. However taking the example above, if the ‘Master Data’ capabilities of our enterprise needed to evolve, we would need to perform the change twice. Once in the AP accountant Persona, and Once in the Master Data Steward Persona.
Example planning of Personas, capabilities, features, and individual roles
You could also structure your roles, using a logical combination of both methods.
Use Type Classification
The architecture of your roles
Let’s take the following requirements/assumptions into account and see how they will affect your roles structuring design choices.
- We have the personas of Asset Accountant and Asset Manager,
- The personas exist in our 2 company codes (North and South),
- The asset accountant can create/change/display Asset Master records, the Asset Manager can only Display Asset Master records,
- Each persona can only interact with records created in their respective company codes,
- To make this example simple, we will assume that they only need access to one Fiori app, one that caters to all Create/Change/Display modes, depending on authorizations.
So, on the basis of that information, can you already mentally work out how many roles you are going to need?
Let’s see how these requirement affects our workflow when creating roles for these personas.
Because we need to distinguish between the ability to create/change vs display, to abide by this requirement, we would need to have 2 different roles
- One that caters for Create and Change of Asset masters,
- One that caters for the Display only of Asset masters.
Separation of roles depending on CRUD (Create Read Update Delete) activities
However, the next requirement we need to abide by, is that each persona can only access the data in their own company code. We have two company codes to deal with, meaning that we need to be able to create/change and display in company code North, and the same applies to company code South.
So, to comply with these requirements we would need 4 roles, as shown below.
- One that caters for Create and Change of Asset masters in company code North,
- One that caters for the Display only of Asset masters, in company code North,
- One that caters for Create and Change of Asset masters in company code South,
- One that caters for the Display only of Asset masters, in company code South.
Further separation of roles based on organizational authorizations
In the example above, we have in the same role combined the transactional and organizational aspects. This is one way of doing it. To emphasize, again, that this is not a must-follow guidance that I am offering here, we could also have created one role containing only the transactional access (Create/Change Asset Master) and another transactional role containing the Display Asset Master access, and then 2 additional organizational roles containing only the organizational accesses: one for company code North and one for company code South.
If we again put this in relation to the FUE concept, the SDG/SUD indicates that Display rights are covered by the Use Type Self-service. This means that the user that has the Create/Change role would be classified as an Advanced Use Type and the user that has the Display only role would be classified as a Self-service Use Type – even though they both access the same app. Again, something to consider in order to keep your FUE consumption in check.
Codification of Roles
Irrespective of how you decide to structure your roles, you will end up with a number of roles, and it will be very valuable for you to be able to identify on the basis of a naming convention what a given role represents rather than having to open the role to find out. Again, planning comes into play here. Say you go live with one company code, and you create a role ‘AP Accountant’. You then add a new company code, but as before you need to segregate this role by company code. What are you going to do? Delete the previous AP Accountant role, and create 2 new roles, ‘AP Accountant North’ and ‘AP Accountant South’? Clean option. Or are you going to keep the old role and create a new one, so now you would have a role named ‘AP Accountant, and one named ‘AP Accountant South’. Not a clean option and a diverging naming convention.
I would recommend that you work on and internally publish a naming convention to structure the code of your roles which will be valuable in terms of structuring, identification, maintenance and assignments to users and contribute toward increasing your enterprise architecture maturity if it needed to be.
An example of this is shown below where we have in Excel laid out the various parts that make up the code of the business role, and then simply used the CONCATENATION function to put it all together. In our case, we have in the codification of our roles used a code for the role, the country that applies, the organizational ID code, and the kind of access this role provides (Create vs Display). The first column represents the concatenated code of the role, as we will use it in the system.
A side benefit of planning here is that you can also make sure that the length of your role codes does not exceed the maximum length permitted in the system!
Codification of roles to prepare the creation of roles in the system
We have also for information purposes added the HR name of the role and the Use Type classification of the role and we will see later why this could be helpful for our planning purposes.
The above is just an example, I would certainly encourage you to determine your own codification/naming convention rules, based on criteria that makes sense to you. I would also like to bring your attention to two accelerators that are available, from the SAP Activate roadmap, that include many recommendations for roles, as well as Fiori Spaces and Pages.
- S4H_3SL_How to set up a Naming Convention (sap.com)
- S4H_2SL_How to set up a Naming Convention (sap.com)
System Usability – the User Experience
As you probably know, SAP FIORI Spaces and Pages is SAP’s future direction for the user experience (UX) when interacting with SAP S/4HANA Cloud.
Without wanting to go into too much detail on this – as not the point of the blog – Fiori Spaces and Pages provide for a great UX when Using SAP S/4HANA Cloud. In a nutshell, it allows you to design how the features a user has access to will be presented to them. You can leverage SAP standard Spaces and Pages, but you can also design your own. I however mention this, as your SAP Fiori Spaces and Pages design hinges, once again on your business roles.
The image below articulates how the business roles relate to the Fiori Spaces and Pages design, and ultimately what the user will see when he logs on and thus his experience of the system, which you want to be great, to ensure adoption of the solution.
Relationship of Spaces and Pages to Business Roles and Business Catalogs
If you would like to know more about Fiori Spaces and Pages then I would recommend you read the blogs written by my colleagues Jocely Dart, Sylvia Strack and George Yu as a starting point:
- https://blogs.sap.com/2020/11/06/sap-fiori-for-sap-s-4hana-best-practices-for-structuring-spaces-and...
- https://blogs.sap.com/2021/02/25/recommendation-for-structuring-roles-spaces-and-pages-in-the-sap-fi...
- https://blogs.sap.com/2022/08/22/how-to-use-spaces-and-pages-in-sap-s-4hana-cloud-2208-release/
So, in addition to designing your roles to ensure that your users will have access to all the features they need to perform their duties, you also need to design the way in which they will consume SAP S/4HANA cloud.
In this case, whilst the Spaces and Pages have nothing to do with FUEs, I mention them, because you want to be strategic and plan for them - you do not want to think about this aspect in a manner that is disconnected from your roles design after you have gone live. This is in an effort to avoid rework later on, but also think holistically not just about what a user needs to do his job, but structure it in such a way that once in the system everything will make sense to them and make their workflow that much more efficient. For example, are you going to segregate your procurement features, from your inventory, accounting …. features, or neatly group together the individual tiles that would allow one to create a purchase order, receipt it, enter the invoice, pay the supplier. Takeaway: think about the user experience.
Plan, Prepare, and Simulate
You have by now decided on the structure and built your business roles, you have identified your personas and know which roles each persona requires, and you know the users that will access the SAP S/4HANA Cloud system and their personas. It is now time to orchestrate all these pieces and ready the information that you will pass on to the person tasked with creating these users in the system. At the same time, if you did your work well, you will be able to off-system, and assess a realistic FUE position.
User, Role, and use type assignment planning
All the information we have put together in this sheet is:
- 1) All the roles that we have created are listed here,
- 2) We have for each user identified the persona that corresponds to their role and thus determines the role(s) they need,
- 3) where the role is required by the persona, we have added a X in the cell where the Role intersects with the user,
- 4) Using built-in excel functions, we can here determine what the Use Type of the user is (i.e. if a user has one role of Self-service and one role of Core, he will be Core),
- 5) Using built-in excel functions we can count the total of each Use Type based on what was determined for each user at 4),
- 6) Using built-in functions we are then able to also calculate the total FUE number that our setup will utilize,
- 7) As said, we want to provide the person tasked with creating these users and role assignments in the system with information as complete as possible, so we have also added the chosen user id’s and names.
Having this FUE number on day one of your go-live is going to be of immense value in your relationship with your CSP (Customer Success Partner), in your ability to have valuable conversations with them on the basis of this factual information, and not execute programs of work because ‘you think are under using your FUEs’. The adage you can’t improve what you can’t measure applies here as well.
Post-implementation. We’re live. We’re done, right?
The fruits of your hard work have paid off, you are live. You might be inclined to think that you are done. You are not. What you do not want, is to let all the efforts you have put in till now go to waste. So here are some pointers that I would encourage you to consider.
Governance
I would encourage you to set up a small, dedicated team of people that are responsible for the maintenance and assignment of roles to users, to make sure that every role change is controlled, compliant and every change measured.
- Not just to make sure that you keep your FUE usage in check, but also to make sure that your data safety and security remains airtight. Users have the appropriate rights and authorizations in the system to do their job, no more no less.
- As and when changes are made to roles (for example during an upgrade you have added new capabilities that augment the capabilities of certain roles), this team would be able to document and assess the impact of a change on a role’s Use Type. Is it still a ‘Core’ role, or has it moved to ‘Advanced’ for example? How does this impact our FUE entitlements?
- Set up a process, whereby every role change is sanctioned by an approval process, don’t give John the Accountant role just because he asked for it!
- Continue to have regular discussions between HR, the business, and IT to plan ahead of any foreseeable changes to roles (think about that manufacturing division that you are going to grow, by adding to it a new warehousing capability!).
System Usage
You contracted 100 FUEs and based on your hard work above, you have deduced that you are using 100 FUEs. Or are you? You have to remember that creating a user and assigning roles to them and consuming your FUE entitlements, does not mean that they are actually using the system! You should monitor this, not to police but to take corrective actions if need be.
As an example, you could check to see which users have not logged on to the system in the last 4 weeks. The reasons for this could be varied.
- The person left the organization, but we forgot to retire their user from the system (This usage is still counted and unnecessarily consuming FUEs Implement a process to offboard users. See later)
- The person is scared to use the system. Maybe you lowballed your training effort or your organizational change management effort and have users that do not feel confident using the system. --> Upskill them so they are comfortable using the system.
- A person is still doing their work, but off the system, maybe because a feature was not implemented. This is a data risk because you are potentially making key business decisions on incomplete vision of data that resides in spreadsheets instead of in the system. Understand the barrier to this person not using the system to do their work in the system.
- You gave a user system access, but this was a mistake, they do not need it. (This usage is still counted and unnecessarily consuming FUEs --> Retire the user from the system.
In SAP S/4HANA Cloud, public edition, for example, you have a dashboard in the ‘IAM Key Figures’ app, that will give you this information.
Dashboard: IAM Key Figures SAP S/4HANA Cloud, public edition – Last logon of users (right)
Each element of the bar chart can be selected to drill down to the list of users represented by that data element.
IAM Key Figures SAP S/4HANA Cloud, public edition – List of non-using users
Assess the validity of roles with system activity
Despite your best efforts to build appropriate roles, it could be that some erroneous decisions were made when you crafted your roles and adjustments need to be made. For example, maybe you thought that ‘Sales Representatives’ were going to require the ability to create ‘Customer Business Partners’.
You should then check if sales representatives are actually using this capability. If yes, then great, but if not, and if the reason is due to an erroneous decision, then adjust your roles accordingly. Doing this might also affect the Use Type of your roles by downgrading a role from ‘Advanced’ to ‘Core’ for example, which will then reduce your FUE consumption, and allow you to re-allocate it to someone else that requires a more expansive access to the system!
Of course, it would be a mammoth task to perform this exercise for each and every role and each and every app, so you will probably want to be selective. Also, as it may be that you will not have a nice report that gives you exactly this information, I would propose as a workaround that you look at the creation statistics, i.e. use a business partner CDS (or app Manage Business Partner) to check if a given user has created any business partners.
In SAP S/4HANA Cloud, private edition, you could additionally also look into transaction SUIM to see if it yields information that is applicable to your investigations.
Off-Boarding users
On and off-boarding users reflect the comings and goings of your employees. For me the off-boarding is maybe more important than on-boarding. Only recently, did a CSP colleague ask for my help with their customer, because their super user had left the organization and they did not know what to do with that person’s user master in the system, nor did they know what they need to do with it. So, to accompany the process of a departing colleague, below are some of the items that you should have on the departure checklist, before and after they leave.
Before:
- If the person is a manager and approves workflows, make sure a deputy is named, so that workflow items do not remain un-approved,
- Decide on a date, on which you will change the Workflow rules, so that workflow items are directed to a successor employee,
- Check to see if any background jobs are running under this person’s user and decide what to do with them (are they still valid, do we delete and re-create them…).
After:
- Once the employee has left the organization, make sure you lock down their access to your system – it does not necessarily mean deleting the user master. You could as a start ‘lock’ the user, change the user validity end date, and remove the roles assigned to them (that way at least the user is no longer contributing toward your FUE consumption). Also, and more importantly, you are making sure that the employee can no longer access your system and thus present a possible security breach or data leak,
- If you are using an IAS (Identity Authentication System) tenant make sure the user is also retired there (you might also assess the other systems to which the user had access to),
- After, some time, you may delete the business user completely from the system (remember that depending on the authorization the user had, you may have to carry out these activities in your DEV, TEST, and PROD environments as well as in your TEST and PROD IAS tenants, for security purposes, but also to make sure they do not continue to consume FUEs unnecessarily).
I hope you have found this blog useful. That it has demystified what an FUE is, how you calculate it, and that the blog highlighted areas that you had not thought to include in your project planning or implementation.
If you have any follow-up questions, then please do not hesitate to ask them below. However, if you have any questions that are of a commercial nature, they will not be answered here, and I would encourage you to engage with your CSP or usual SAP Commercial contact.
- SAP Managed Tags:
4 Comments
