Thank you so much. Good morning. This is maybe a bit late to say good morning, but it's still before lunch, so it looks like I am the last one before the break. It's my pleasure to be here one more year. This is four in a row, explaining how we are doing the things in Holcim. I used to be a quite practical guy, so I would like to define myself like this. I'm not here to explain how we are doing the thing, just to explain how we are solving the problem. Also to go one step further and show the solution in action, show the solution working.
So being able to show you in a video the outcome of the things that we build. So first thing, this presentation is about end-user experience. It is good not only focus on management in natural language, because it is something that has been presented before. So it will be about end-user experience. And as you know, the users are not familiar with the IGA. So the users are not often able to understand what is the best way to request an access, even what is the best way to approve a request, who is the next in the approval flow. So it is not easy enough.
And from our point of view, the solution should be easy enough in order to be consumed for users who are not IT guys, who are not techies. So for example, and I'll be introducing Holcim in a bit, a little bit. So our users are not really expert on IT. So just summarizing quite quick here the agenda, so what we are going to talk today. So first contextualize who is Holcim after share with you our motivation and requirements, explain how we have improved the experience, and finish the session with main takeaway that I'm expecting that you got after my session.
So Holcim, for the one not knowing the company, so it is a company started in the building material segment. So we started producing cement, ready-mix, aggregate. Now we are moving forward to be more sustainable. We are also putting in place more innovation and doing houses which are 3D printing and things like this. So somehow trying to modify a little bit how we are doing and how we understand construction. And as you can imagine, this is a quite large company. So overall worldwide, we are more than 50,000 employees. And we have several identity platform and it represents some challenges.
So speaking a little bit more about the MIA region, which is the main area that I manage together with my team. So we have more than 38,000 employees. So we produce service or deliver service to 42 countries. And we are supporting 19 different languages or people from 19 different cultures. As you can imagine, it's a big challenge. So contextualizing a little bit more about our EGA project, because you are here to listen about EGA. So this is our figures. So just to give you an overview. So these are the number of identities that we have. More than 38,000.
We have, as of today, more than 180 applications connected. And the number of requests that we are managing per day is between 300 and 400. Okay. And now I would like to do any kind of, I would say, survey, poll. So I will request a little bit your collaboration. We are not that much on this room. And I would like to understand if any of you have ever heard any of these comments. So we have our first guy here. And the first guy says, I am the best using EGA, but always requesting correct items. Maybe familiar for something? Have you heard it before? So I have another guy.
And this guy says, hey, I am a bit reluctant to use my corporate device. I need to access anywhere on any device. So most likely you have here as well. So I have another one. I would say, I simply have no idea about how EGA. It is not fairly enough. I do not want to enter there. I am not able to do any single stuff there. And I also have another guy here who says, I am always traveling. I need to approve access requesting on my mobile. I want to do everything on my mobile. Okay. And I say at the very beginning, it is not only about management in natural language.
It is also about end user experience. So the idea is to share here what it could be achieved as a quick win and what could be achieved as a bit more mid-tier solution requiring a bit more effort. So when we have contextualized it, it is important to understand our motivation or our requirements, why we decided to move forward on this direction. So first thing, as you can imagine, as I have already explained it, is access from any device anywhere. Something which is clearly demanding. Simplification. So simplification in terms of approval process. Simplification in terms of access request.
Try to do this process as simple as possible. And for sure, easy access to EGA. So avoid to have just a single place to interact with the EGA. So put it a bit more freely and to facilitate different paths in order to allow the user to access. And it for sure will reduce the overload to the headers. It will for sure reduce the call that the guys are at the end attending. And it has to be in composite, as you can imagine, keeping the compliance and the security. So it is good to be user-friendly. It is good to make the technology more accessible.
But the EGA solution are at the end security tools. So we need to guarantee this stuff. And it is in composite at the end to have an end-user experience which certainly nowadays has to be leveraged using EA capabilities. So next thing here is let us see what we can do quite quickly. So let us see how we can start improving our end-user experience just investing a minimum portion of time. So what we can do quick. So first thing is put our EGA solution accessible anywhere on any device. So it is important to allow the user not only access in the network but also through Internet.
And allow the user to access from anywhere, any device. And you can easily do it just using a split DNS concept. So the user will be connecting to the solution either if they are in one place or they are in another. And here it is for sure important to take some security considerations. So you have to do what you have to do well. So the idea is not to do it and be compromised. So here it is important to enforce MFA authentication where the user are entering to the EGA, especially when they are entering for Internet. So configure the network firewall properly.
So opening just only the required port. So put also an integration with the same solution in order to redirect the events and to start leveraging ITDR capabilities. Deploy a web application firewall. Not put the protection only in the network level but also in the application level. And it is always a good idea to execute regular web penetration testing to see if it is properly protected. So with one, something that could be easily implemented but should also be securely implemented. What else? What else is normally helping and it is a quick win to improve the end-user experience?
So approve or reject your email. Sometimes just to approve another request or to reject another request, it should not be necessary to the user access to the EGA solution. So they have to be able to just replay to the email and replaying to the email decides if they want to approve or reject. So if you want to have granularity, if you maybe have another request with 50 items and want to approve 30, reject other 20, it is maybe good in the solution.
But in some other requests where there are not many staff and the decision is to approve or to reject, it is maybe a good idea just to do replaying to an email. How to do it? So it is easy. So here you have a quick, easy, I would say, architecture diagram. So at the end, you have to put a button embedded in the email. This button will be invoking a gateway. So in this case, it is doing a call to an API gateway who has a Lambda function behind, and this is the one at the end moving or transmitting the decision to the EGA platform.
So quite easy one, quite easy stuff, something that it could be deployed in two, three hours easily with any EGA platform. So here also important to take in consideration some items, some things that you need to take into account. So the first thing is that the buttons to approve or to reject should be embedded in the email, and it should point to the API gateway. So the work item to be processed must be encrypted and has to be decrypted in the moment that the decision is taken in order to ensure that only the recipient of the email is the one who has approved.
And also it's good to know that it is more suitable in the case where there is just one person in the approval flow than in the cases where you may have workgroup or any other staff and it's maybe not that easy or not that straightforward to keep the accountability. Okay, so let's continue here. So the next thing, and this is the main stuff, is EGA management on natural language. I decided because, you know, as of today there are many sessions, many presentations, we put the focus in the LLM, so I could understand that other sessions or other presentations put the focus on this case.
So here it is a format of chatbot. So this is an agent, an EIAgent, because it is not only answering, it is taking the decision in the system. And here I am going to explain how we have done it and for sure show you it working. This is the idea. So first thing, identify the process step. So the next one is the use case definition. So taking into consideration the time that we have for this session, I have decided to bring here four. So four of them that we have is request access, check the request status, manage the approval, and somehow put the help material available to the end user.
One thing that we have to do as part of this process is to extend the API of the EGA platform in order to support this use case, because not always the API is supporting that. Build a frontal layer, so you need to have a frontal layer. In our case I say that I will present today in a format of chatbot. And for sure it is always good to embed in the platform in a plugin format, as the previous colleague commented before, in order to ensure that the user go to the place that they used to go, which is the EGA solution on this case.
So for sure it is a good idea to share with you the solution architecture diagram. So as you can see here, it is not that complex. It has been highly simplified. So we have our front end, which is the place where the user go. Then we have our EGA API embedded with a plugin. And for sure we are connecting, leveraging the API that the EGA platform is putting. We are also using in our case another database in addition to the one to the EGA solution. And this is a database that we are fulfilling with an IE worker in order to have the information already calculated.
Already calculated such as the recommendations, such as the peer, and all this stuff. Make sense? Really good. So now I understand that you guys want to see the solution in action. I understand that you have already been able to identify what EGA solution are already using. And now let's see it. So in this first use case, let us imagine that I want to request for access. So the next thing that it is asking, it is for you or it is for other user? So in this case I say for other user, give me the email or give me the username. So putting the email there. It's this guy.
It is the one that you are looking for, yes. For which application? So here we reduce it to SAP. How do you want to identify the access? So based on the peers, meaning the user reporting to the same manager. Or it could be based on the position.
Okay, based on this one. So let me calculate and let me identify what this guy have and what you do not have. So it is the one that you want to request?
Yes, I want this one. After that they start to do an SOD analysis. Do you want to create another request? Do you want to manage this?
Yes, for sure. And at this time it is creating the other request. And for sure ending this process with the other request number. So here showing another use case, which is the request status, the previous request that was created. So it's just as easy as put there the number of the other request, the number of the work item, the username or the email for the person which is expected to get this permission. And you can see here the information. And the good thing is that in the cases where the approval is related to a work group, it is also listing the people who is behind of this work group.
So the user is able to know how to call it if they need to have this access in a rush. Okay, next steps or what thing we are doing as of today. So we are improving the way that we put our heal materials to the end user. So we plotted there together with all the context information that we have been collecting for years in an LLM in order to be able to easily ask it and to explain the user how to do the things in a bit more easy way.
We for sure, and this is already done, publish the copilot in different things in order to be more accessible, not just on the EGA platform, but another thing in order to redirect the user to this interface. For sure, we started with some application and we extended the coverage. So I saw what here for SAP, and we for sure did for other, but we are extending or doing the process as freely as possible for different application.
And one of the thing that the EGA vendor is doing and the previous call it also explaining and we are working on is enhance the description for roles, entitlement, and other object that we have with LLM capabilities. Okay, and I'm almost there. So it is always so important to get takeaways on this session. So fair ones that I will say it is important to put end-user experience at the top. So it is important to assign the appropriate relevance to this stuff in order to be able to deliver fairly tools to end-user. Try to avoid mistakes as much as possible.
You see that the process is quite guided, that the user almost has no possibility to mistake. So if you open a lot the possibilities that the user come from, most likely you will have scenarios which will not be properly addressed. Another good takeaway I will say that simple item such as the one that I was showing at the very beginning sometime could bring excellent results. And the last way, it is possible to innovate with no cash out because it is something fully developed internally with good guys working on my team. And it is something which certainly add value to the business.
Last, leaving here my LinkedIn, just in case you want to connect or just in case we have not time enough for question, I'm always happy to have discussion, to catch up, but I think we still have one minute or so. Okay, perfect. It means that I was quite clear or you guys understand nothing. Okay. I'm just...
Oh, sorry. No, in terms of coding versus like system prompts or whatever to get copilot to do the whole chain, show those nice little buttons, little check boxes. Behind that is basically a big system prompt that tells you what to do. And then there is a set of skills that you define that then attack the API that you showed in your architecture picture, is that it?
So, I guess my question is how much coding versus how much just system prompts, right? So, I would say coding is, I would say, around 30%. If you are trying to find a balance, so in the front-end it is, just to give you a little bit more information, it is something that in our case we have developed with Python and we have put a street lit, which is a front-end technology for the Python code. And I would say that more or less 30% is the amount of coding that we have versus the capabilities that we are getting out of the bot from other things. Okay?
Yeah, thank you for this presentation. Quick question, you mentioned that the data quality like role descriptions are crucial to always improve the output of the AI tool, so how do you approach this to get good quality descriptions? I guess you have to talk to the business as well to have a really good quality there.
Yeah, I will say that it is important to have, certainly at value, but you saw the demo, I will not say that it is so crucial. You have the possibility to identify what you need based on other patterns.
So if the only way that you have to identify what you need is just searching based on role description or role explanation, it has to be good quality, I will say, and you know, there are technologies there in order to enrich the data based on documentation or based on an external source and things like this, but as a main message, I will say yes, it is important as better information you have, better decision will be able to take the user, but the idea is that the user in most of the case will not even need to know very well the description or will be able to identify what they need based on peer position and this stuff.
This is the main message here. All right, and thank you so much, Samuel, again.
Thank you, everyone.
