Greenfield or Brownfield?
When planning an S4 implementation, have you as a security owner asked yourself the crucial questions around your current SAP Role state? Are you comfortable moving your current roles into an S4 environment and adding the necessary Fiori apps to meet the business requirements? Will your current roles stand up against risk analysis through your business rule set with the introduction of Fiori (or even without)? Have you proactively engaged with the other product owners about your decision from the very beginning? These are the fundamental questions that must be asked when planning your Security move to S4.
The Brownfield implementation method is currently the least commonly used approach, and with good reason. As the name would suggest, a Brownfield security approach aims at re-using your current SAP roles and retrospectively adding in any Fiori applications based on the requirements given from the business which would be mapped in their business processes. You might ask why is Brownfield the least favored option? An S4 implementation not only brings new functionality to the ERP Eco system but fundamentally reshapes the processes of a business. SAP have striven to standardize business processes through Fiori Apps, which means there is a high chance the ways of working will change for all SAP end users using S4. Going on this premise, SAP have introduced a “blacklist" of all Transaction codes that are now obsolete in S4 when compared to ECC, (a full updated list can be found at the end of the blog). So now you have a situation where all the obsolete transaction codes must be deleted from your already existing roles and replaced with the new Fiori Apps that have replaced this functionality, and some Transaction codes do not have any correlating Fiori Apps which replace it. SAP is historically famous for its customization and within Security this is no more prevalent than with Z transaction codes. As mentioned above, SAP are now trying their absolute best to standardize as much as possible, so an exercise needs to be carried out to check if all Z tcodes that are currently assigned to Production roles are still valid and do they function correctly in the Launchpad with sufficient authorization checks in place.
Possibly the one of the most time consuming phases with a Brownfield approach is the usage analysis phase. Transaction code usage is a key decider on what goes and what stays, for example: If a job position or user has 200+ transactions assigned and only uses 150 of these transactions over a 13 month period, then there would be no reason for these 50 odd Transaction codes to be assigned. Reducing the amount of tcodes assigned to users/roles goes a long way to improving the performance and user experience for SAP Launchpad. Project Managers often overlook that security is inextricably linked to the improved user experience offered by Fiori and must therefore play a bigger part to ensure a successful S/4HANA conversion.
As you could imagine, when a business migrates 1000+ roles from an ECC system into an S4 system, you are inevitability going to shift the already existing risks from ECC into S4 and still be in the same position as you were before. Its also worth mentioning the countless different naming conventions that tend to arise in a mature ECC system. As processes and consultants/employees come and go, the naming conventions are bound to change, and the security role builds from composite to single are also going to change which ultimately leaves a mishmash of different names and approaches which you do not want to carry into a newly migrated S4 system. It might also be an idea to consider the approvers and owners of your current state SAP roles. Has there been a re-org recently, have the approvers and owners changed?
As we have a seen global mass movement to cloud based systems, many of our customers are currently utilizing cloud based HCM and Finance systems which interact with their S4/ECC systems, for example SAP Success Factors. A common mistake we see with companies around RBP administration in Success Factors is the neglecting use of the standard connectors which SAP provide with GRC 12.0. This is possible of course to implement with a brownfield approach but a cleaner and more efficient approach would be to roll this out with the wider greenfield approach.
In a survey carried out by Corrib Consulting, 75% of companies have said they would not be happy with their current role structure in SAP and would prefer to undertake a Greenfield approach to their SAP Security S4 implementation.
So why go Greenfield? As we explained above, there is technically no reason why a company can not choose to go with a Brownfield S4 Security role methodology but one would have ask the hard questions, is the current state really good enough to bring into a brand new system, would you be happy to bring in existing roles that are filled with potential legacy risks? Companies now have a once in generation opportunity to build their processes from standard, without the added complexity of custom developments and security is no different.
The below role build methodology from Corrib Consulting seamlessly integrates with the SAP Activate Methodology of Discover, Prepare, Explore, Realize, Deploy and Run.
Ideally, when the business are in their Discover, Prepare and Explore phases, they would be gathering all their requirements and part of their requirements involves identifying all the needed Transaction codes, Web Dynpros, Fiori apps, etc that are needed to carry out those particular processes. Using this information, it then becomes more straight forward for a security team to build streamlined roles that align directly to business processes. Its not just your business Catalogs that need align to your business processes but also the UI layer and how its presented to the user. SAP have introduced the Fiori Launchpad and its the security team that shape how the access is presented in groups, pages and sections. If you have already mapped your processes within the Business Catalogs, then arranging the Launchpad tiles for these users in a way that will boost their efficiency will not be a huge task as most of the work has already been done.
Following on from this, is it possible to group these processes into container roles for particular job roles. Job roles are not just defined to one system, if we take the example of an AP Accountant, an Accountant may need access to SAP Analytics (SAC, BO, BW, etc) systems for reports, SRM systems for procurement activities, HR systems (Success Factors), Expense systems (Concur), etc. Using our container role mapping methodology, there is an opportunity to map all of the required access into one single access container, which can be requested and granted in one single GRC Access request, thus drastically improving user/customer experience whilst reducing the wait time for access for your business, not to mention freeing up your security admins for more value added tasks.
To summarize, there is no silver bullet to this scenario, there is no right or wrong approach but your business can make the best decision if the right questions are being asked and if the current standards and operations are challenged and scrutinized to achieve a future proof design and a better ways of working for your users.