Hello, I'm Amit. I work as a senior manager with PWC Netherlands. I have almost two decades of experience in implementing and consulting customers on identity and access management. Today I'm going to talk about a topic that I continuously see with many of my customers currently has rightly mentioned that there are very few customers who operate without SAPs and how the new transformation that is S four HANA is bringing in and the questions being raised, the challenges the customers are seeing in terms of IM is based in that domain. What we see typically, what we have seen in various customers been working and how we try to consult them and what are the solutions that we propose around those challenges.
I'll talk about what S for is bringing in what are the challenges in terms of Im, what are the traditional SAPs identity architectures being implemented? What problems do they cause or what are the reasons behind it? And how do we consult our customers in future, how they can integrate SAP more with IGA solution. Before that, going to the IM topic but what is actually S for Hannah as for Hannah is rated as one of the most significant upgrade by SAPs in last few years. It is upgrade from their business applications to in memory database hana, which will be only be supported on HANA database, not other databases. And the licensing and support for the existing business applications will be ended by 2027, which essentially means the organization which have been using SAPs will not have a choice but it's just a matter of time and they move to has for HANA upgrade. As for HANA upgrade is considered to be very fast an open architecture system which will allow not only just SAP data, but various other databases to be integrated within IT to show reports, create views for the end users, allowing users to run very quick reports on those databases. It is available on-premise as well as cloud will provide a common web interface name Fiori across platforms like mobile and com, laptop cetera, et cetera.
It'll integrate various business applications in one platform, again supported by the HANA db, which can be enhanced by various modules. For example, if you want announced HR feature, then success factor would be a module that will, you will put on your S four HANA till 2018 s. SAP reported. Almost 9,000 customers have implemented it and of course with the license end of support coming near soon, many more customers are going in it. What we typically see from an IM perspective and customers talk about upgrading the authentication module has changed a bit considering that now database will be the core of providing access and reports to business as well. And there will be very less business layer in between.
The whole access is provided in terms of DB views and with the in-memory database fii. And on the top I'm showing what are the modules that can be plugged in to enhance the features of S four hana. What we typically see is with the dynamic nature that they're presenting with open architecture, the HANA database can also pull in data from even social platforms like Twitter, et cetera, to provide your reports. And this has created a huge number of roles if it is left to the database administrators to generate it. We have seen number of roles more than the actual employees in the organization. The role names sometimes have seen like role one created for this person
And and that creates an issue if not centralized in terms of the role management. The second challenge we see is in terms of a direct DB access, which is given to the end users or to the business as well. This creates role catalog management a bit difficult as well. Again, if you're using SAP IDM and there'll be thousands and thousands of roles coming for the users to select, then we typically see that the common web interface which allows you to even create web services out of the DB itself, the business layer itself is not present and that creates challenge in terms of access management, how to control various APIs and how, how to control the web services around it. And considering that now Shan is integrating more with non SAP world, we have seen customers talking about re-looking at their S od structure, redefining the S od rule sets, how people are now gaining access via click on Fiori via module or via dropdown. These are some of the challenges that we see when we talk about SHAN upgrades going on. And that's a non, that's a non-technical challenge that I typically see when SAP is becoming so integrated, the whole sap, IT itself becomes very powerful and very separate kind of team. It becomes challenging to even convince them to come to the mainstream IG and talk about solutions of giving up for example GRC or for example giving up SAP idm.
These are challenges we are seeing in terms of SAP upgrades but and typically what we've seen in the past, how SAP IM was working in the past and before that there used to be typically SAP separate structure, SAP and SAP GRC for OD provisioning and all the non SAP world would be on IG if the organization is mature enough.
And that's how they used to operate in, in a siloed environment, not talking much to each other. And this we have seen in terms of issues, one is the major compliance issue that we encounter is a missed SOD rule sets. For example, if a user has invoice creation for request or accessibility in SAP environment and payment in some bank application access between SAP and non ssp, which should create a toxic combination but it is not checked because of the siloed approach in terms of IM OD rules set itself are in different systems and nobody's able to view that common OD check that should have happened.
Second thing we see is audit response for, for example, a very common question also that who approved access to this system, the IT support team or the audit response team had to go to two different organization to different teams and ask the same question, collect the reports and give it to auditors. And finally, from user perspective, we typically saw that especially in firefighter kind of access that people had to go to cyber A for maybe another PAM solution for a privileged access for sap. They used to go to GRC to get the privileged access. And there were two typical reasons for keeping the GRC that we heard was one is GRC is very good in maintaining the s o d, the T code level S od rule sets. And second is for privileged access. It is very good in maintaining the logs and also highlighting what was done and what was incorrectly done, what decodes were used, et cetera.
And there, there are right reasons. Previously the IM solutions were not capable enough to replace DRS in terms of the privileged kind of sods or the granular level of sods and the kind of rule sets that were available in grc. But with modern solutions, what we are suggesting our customers is more on option one, which is I personally see is more tested, more accepted in the SAP teams, which may, which says that SAP GRC remains as it is the rule sets of SAP remain in grc. But for users access request common IGA becomes the common platform and the IGA talks to the GRC whenever there's a request, the sods are checked between GRC and your non SAP world, which is present on iga which removes the problem of the missed rule sets, the interface becomes common and also satisfies the queries of SAP team that is IG a really capable of replacing grc. The second option which is more elegant, looks great and in terms of supportability maybe a better solution is completely move out of sap. IDM and GRC have all the rule sets in ig, all the provisioning in IG and treat SAP as good as your non SAP systems.
My experience, we have not completely implemented it somewhere we have tested it. Technically it works but again one of the challenges the SAP teams are very, very strong in terms of their opinion on gsc. So at least in my experience, I have not seen a customer replacing complete GSC till now. Firefighter is something that people say that GRC is the best solution we have. We have been started suggesting people to use your PAM solutions for looking at firefighter access as similar to a shared privileged account for other applications, which means we onboard firefighter accounts to a PAM solution. We maintain their membership in an IG solution which essentially means that if I join an organization I say that I'm part of SAP IT support and I will need firefighter access and ig. The IG approves it says yes, you are good to go. Provisions mean PAM group and says that this, these people are allowed to access PAM firefighter groups.
I'm trying to explain it with a use case. For example, I want to access a firefighter access for two hours. I'll go to Pam solution, say that gimme access to firefighter one rule for two hours. The PAM solution will say that you're part of this particular group. Yes, you can access it, open the window, create logs, stores it, and rotates the password whenever needed. And with the new capabilities, it is able to monitor and tell you what kind of critical access or report to the SAP admins that this particular user used a very different kind of access, which is not normal. And ultimately IGA can take care of the governance around the group membership in a sense that it can remove your access. Let's say I move out of organization, it can remove me from that firefighter group, it can do the certification of that firefighter group which GRC was not giving that overall solution.
In terms of the governance of firefighter group access, this essentially means that we are suggesting typically to customer to move out of GRC as much as possible and integrate with IG and catering to the two major challenges. That is the S O D as well as the firefighter access. And I think I have successfully at least implemented the first part, the option one at GRC integration between IG and not just one customer may few customers already and few POCs on completely removing GRC and doing a complete IGA solution. And this definitely is a solution that works very well without grc. That is all I wanted to talk about in terms of S A P grc. If you have more questions, please feel free to reach out at PWC booth. Thank
You very much.
Thank you.
So well that gives us ample time for questions. There are no questions in the chat as of now, as I see. So other questions in the room. I think there are many organizations struggling with unifying I, IGA and sap. Maybe we can, yeah, there's a handover there. Thank you very much. throw it.
Yeah, thank you for the nice presentation. And the question here would be, have you considered the option to actually unify the user experience on top of still two solutions, which would be one non SAP and one sap, but still unify the things on a higher level where end user doesn't has to need, has the need to know if they're accessing SAP or on sap they just ask request access and then on a lower level a workflow decides if that should be SAP or not SAP and addresses the correct system.
So for question, you're saying in terms of user experience, I should have unified view of requesting access to S A P and non S A P? Yeah,
I think one of the use cases, and that was probably one of the topic in my mind to present, was we have seen many customers asking why should have a separate service now and an IG solution. Some of the applications are roasted on service now. Some of the applications are roasted in IgM. My user never knows where to go. There are very clean solutions currently present by IG tools, SalePoint, avian, they all have these apps on ServiceNow, which allows you to throw the pages from IGA to ServiceNow for end user. They will feel like they're accessing ServiceNow. But actually the pages are coming from the IGA tool. And the reason for pulling the pages from IGA is IGA can do a lot of sod check provisioning, et cetera, which ServiceNow's probably not capable of. And the overall governance, we still need to use ig, but the end user can get a view that there's a unified solution. It works for I would say medium complex customers, but few of my large customers still wants to go with IG as a pure solution because to protect their crown jewels and not to create complexity that ServiceNow has some data and IG has some data. Many of my customers have audit as a single point of view while user experience can suffer a little bit, but then they go with IGN ServiceNow. But few of the customers who keep user experience are the highest priority, then yes, that solution works.
Okay, great. Thank you very much. Thanks. Other questions? Yeah, okay. That's easy with the microphone.
Hi, I, I like what you're saying. I, I think there's a lot of truth with the, you know the, the ease of user access. It's not something that SAP is traditionally addressed, right? So the ability for users to get that make those requests easily is, is really important. But, and that's all good. But one of the difficulties when we've looked at this from an an IGA point of view is, and one of the great values that SAP GRC brings is that native rule set, right? Like I don't, you tell me there's like, I dunno, tens of thousands of rules in there and I, I guess that's what you're paying for right? When you buy that thing. So getting those rules out and expressing those rules, we get asked a lot of time as as an IGA vendor, I work at one identity so we get asked, well where's your rule set? We're like, well we've got an IGA platform, we don't have a rule set. You tell us what rules and we can do and of course we can import them as well. So I would like, I'd love to hear from you what's your experience? Cuz you, you're, you know, a specialist in that area. So what do you do with these rule sets? What do you, what do cus what do you do with customers around that?
So I typically have a customer for example who had a GRC and we were talking about moving the A P GRC to ig. They already had a rule set and, and I think you're very correct that friction comes in that the A is providing ready met, rule set, what are you bringing on the table? My idea of saying that you already have a rule set, are you going to keep on changing it continuously maybe or maybe not. And and to be honest, I lost that argument already. They are still using a grc but if you're not changing your rule set and your IG is capable of importing that rule set as it is and will work, then I think business should rely on defining or enhancing their rule set on their own rather than SAP telling them continuously they should be a rule set. Just buying a product for the SOD rule set is something I find a little lazy approach. But yeah, I, I think you know the customer
BEC because it's a generic rule set and it's not specific for your business and if you don't, if you don't know what you've got and what's important to you then then you know who does. Right. Okay, thanks. No, that makes a lot of sense too.
Thank you very much. And we have time for one more question. Thank you. Won't be shy. So then I'll jump in. Enabling consistent governance across these platforms with the different approaches that you described can be difficult. Do you have any best practices how to really make sure that you understand cross-platform, so d and maintaining that, so SOD meaning SAP here and non SAP there and cross-platform od there. How do you, what would be some takeaways for the, for the audience to use when they have this issue?
So I think I would probably go a little slowly in a sense that as Martin said, there is to be in between approach. What I tell customer is go with a grc, you have a rule set, connect your a GRC with your ig, let those two rule sets work together and once your SAP team has confidence on ig, move your GRC rule sets to IG and move to an ultimate approach of not having GRC in between. Having rule set in one place works very well, but you won't get there very easy. You won't be able to convince many people to do that right away.
Okay. Thank you very much and I think that's a good re recommendation and I liked your firefighter slide, this is really beautiful. Thank you. Thank you.
