So thank you very much. And I've got the pleasure of the 2:00 PM session. So after lunch, everybody's kind of falling asleep, so I'll try to keep you awake and yeah, first and for, I would like to tell, tell you a little story about the success for implementation of user access management in the company I work for. And actually I shouldn't be standing here for that because I can't claim too much of honor of that. Actually the team should be here and a good part of the team is also here. So you can speak to them later, if you wish they actually are responsible for that success. I would like to tell you about, I would also like to thank the organization of this event because it takes place 10 days before the champions league final in Wembley. And I would say that is perfect timing because in 10 days when Doman gets the cup, I would have never gotten a visa for Munich anymore. So today I can still be here. That's good
So let me possibly start with the company I work for and give you a brief overview of what that is about. I work for the company and maybe, you know, the singer prince. So when he had like some legal, some legal fight, he had to rename himself into the artist, formally known as prince or should briefly tough up. I work for a company, formally known as I energy trading. And it's now called I global commodities. And it's located in Seldorf and you can see the place here. It's the media Harbor of disor, a very nice place to work in. And this is also important because this is the way to attract traders, to come and work in a place. These are the guys who work in London and, and they like fancy places, fancy cars and everything. And also in our company who will find big cars like Ferrari and Porsche and so on. So that is the way traders have their lifestyle and work.
And maybe not to focus too much on the facts and figures that you see here. But just to rather give you an overview because you come from different industries and just to give you brief overview on what trading actually means. And commodity trading actually means yes, we trade power. We trade gas, liquified, natural gas, we trade carbon and, and weather and coal and whatever you can imagine as a commodity, this is traded physically and financially in the house we work in. And just to give you a background on where that comes from. So Aon is a multinational utilities company. And as a multinational utilities company, you have power and produce some, some energy, some power. And as soon as the power is like, yeah, foresee to be produced in two, three years time, then it is already sold from the generation companies in Aon to energy trading or now Aon global commodities.
So we take the power way before it's produced, and then we sell it on the market ahead of time. And in the meantime, before it's consumed, we buy it back and then we sell it again and we buy it back and we sell it again. So before the power is actually consumed, it is, I would say, sold on the exchanges, like in light, it's sold five to seven times, and this is the business of trading coming from asset based companies. And then on top of that, you think, well, if we are trading so much in the markets, why shouldn't we just extend that and do some proprietary trading to earn some more money? And that is what we also try to do. And this is kind of the background on where we sit and you, you attract traders and you attract traders and traders per definition are greedy people. And there is a risk that these people even ignore the rules, ignore the laws. And we have seen that in the past in other companies, but are also in our own company that people have broken the rules and to prevent that you have to actually install. One thing that you can do is to build a firm and solid user access management system.
So to start with a motivation, why should you have user access management? I would like to ask you three simple questions. Question number one, if that was your car, who would you give the keys? The question number two I have is if that was your club, who would you let in? And the third question is if that was your trading floor, and this is our trading floor, who would you give the permission to trade?
So that is actually for us, a big motivation to say, we must have a strong user access management and the motivation of the drivers for that come from different angles. So, as I said before, all the power that is produced in, in a whole of Aon is handed over to us to sell it in the market. So we are not only, or not basically a trading house. We are a risk management company. So we carry and manage 80% of the whole Aon risk. And on top of that, there is the financial risk of that. The traders can do fraud sections. So at the end of the day, that can cause a multimillion or even multibillion loss and therefore ruin the whole company. So that is a high financial risk that we see
One other driver that we saw energy trading as the former name of the company is, was founded five years ago. And well, it was a lift and shift approach. And so you must imagine, and just the do of everything was taken together from, from whole of Europe, from places in UK and Sweden and, and everywhere in Europe was taken together in one place in Des Sudor. And the same people are like working together there with their old systems, their old processes, et cetera. So was all a chaos. And now we have matured over the last five years and the spirit of the company has changed from a startup company to a more mature company. And that enables us also to use and introduce more mature means in user access management.
What I told you before is that we also see external pressure on us because we see in the press, what happens to, to all the people and what the traders do. And that also enforces that the auditors come back to us and look more deeply and, and more in detail into what we do and how we do it. So they ask us to introduce stricter rules and, and force stricter rules. And on top of that, we also in the company have changed over the last five years into simplifying our it landscape, simplifying our processes, harmonizing our processes and all that gives a solid base now to enable us to do a better user access management.
Basically the user access management we have had in place before was based on two roads. And with these two roads, you have a solid base already to be able to do strict user access management. And I'll try to explain you now what the roads are and how we, how we roll them out. So who have you knows this guy, shout it in. Nobody, nobody dares, but it's you have now. And what's he famous for apart from founding Playboy, he is also owner of several nightclubs. And if you ever had the pleasure of meeting one of his parties, this guy knows how to party, but this guy definitely knows who to invite and who to keep out. So the business application owner role that we defined in our companies, that for every application we have, we have a business responsible person who knows who to let in and who to keep out.
So setting the rules and restricting the access by defining who he or she wants to have in the system or not. That is the role and responsibility of the business application owner. And then on top of that, we need another person. And I don't know who this nice guy is, but he will definitely keep you out if you're not allowed to get in. So he's the bounce or the doorman. And that is kind of what we see as the user authorization controller, user authorization controller enforces the rules, which were set by the business application owner. So he keeps the persons out or in, and with this simple concept, you could have a very good working user access management. The people took their role seriously, but as I said before, we have traders. So the traders say, actually, no, this is not my, my duty. My duty is making money, right? And my 10 millions, 20 millions, 30 millions. And that is why we have to always tell them, no, you have also a duty to enforce the rules or to set the rules of your systematic environment. And that is your responsibility. And that's what you also get paid for. And that is what we call creating awareness.
And based on that concept of the people and roles and responsibilities, now you can build a systematic solution. And this is what we started as a join in end of 2011, beginning of 2012. And as I say with requirements, it's always good if you know what you want, and we have seven minimum requirements here, which basically define what we want first. And for all we want to know for a certain system who has got access to that system, we want to have that information always accurate at hand and say, Hey, this guy has left the company. How can he have access to the system still on top of that, once we have looked into, okay, who has got access, we look into what type of access does he or she have. And is that correct? Then we must look into the next question, which is, okay, we know now the person has this and that, and that, and that access in the system, does that all work together? What does it create a segregation of duty issue? Like for example, somebody can enter a trade and at the same time confirm the same trade, which violates the four ice principles. So we have to check that as well.
And then as the next step we ask, okay, if there are any violations, okay, maybe we want to have it as an exception, but then we must know what counter measures do we have in place to mitigate the risk that occurs when we allow this specific violation. So these are the four basic requirements. And then on top of that, I've got another three, which is that the system has to be able to adopt to organizational changes very quickly, because I've never seen such a thing as a stable organization. And we've just recently had a life reorg, but, you know, after the reorganization is before the reorganization, so the next one is upcoming probably soon.
Then we have to define the processes for user access management and to assign these processes to certain people and have them responsible in that. And with all that together, you see that the first four are more or less functional requirements within the it solution of the system. But the last three are not so much it balance. So you can immediately understand why this project was never an it project, but it was a joint it and business project. And this is how we set it up. So it's not only the it solution, the first and most important step is for all the it people of course, to find the right solution and to define it and so on and install it and implement it. But this is like a car without, without petrol. So it will not run.
What else do we need? HR data cleanup. We need clean HR data all the time. It has to be clean. So the people in the system must be accurate and correct processes have to be set up to keep the data clean and to enable us to always track the user access situation in the company. And then this has to be operationally integrated in some part in the company. So in the company, we must find the home of user access management somewhere. And this is also very important, but also very critical step that the project had to define actually, where, where should the operational responsibility lie after the project has ended
Coming briefly to the selection of the it solution. So this was done with a very good help of cooking a call, and we have started actually with good look into what is existing in the market. And then we came up with like 20 possible options as products. And we send RFIs out to 20 suppliers. Well, not all of them responded. So that's life from the responses. We selected six vendors where we took a closer look and had discussion rounds with them, et cetera. Then we narrowed it down again from six to two and with a final two in the round, we made a proof of concept and that was done for two weeks time. And as we knew, the proof of concept would be coming at some point in time, we of course defined the proof of concept and designed the proof of concept in Pavlo.
And this proof of concept was based that we said, okay, in the first project phase in 2012, we wanted to connect the eight most important and most risky systems that we have for the proof of concept. Let the vendors show that they can demonstrate it with at least two out of the eight. And that based on six use cases, which they did and two or three weeks time. And after that, we finally selected a vendor and the vendor was the one that gave the most structured approach. It is the Italian vendor cross ideas with their ideas solution, which we have implemented
HR data and HR staff data reporting. Next pillar sounds so easy is so difficult because if you look into the HR data that we used to have, there were people who left the company, people were assigned to the wrong departments, et cetera. So you have to clean it up, but after you've clean it up, you have must make sure that it stays clean. So we have established a couple of rules, like for example, every employee exists only one single system, or there's always a line manager also for externals. There's always a responsible line manager. And yeah, that has to be ensured to stay clean by a single process. And everybody has to use the same process so that in the future, the data stays clean. And with that, you have a unique idea. And unique idea is really, really important if, if the auditor asks the end of the year, a question like, okay, on the 14th of May at 2:00 PM, who did this, this trade and you come up and say, yeah, yeah, yeah, this is probably this person, but actually we share this idea or whatever.
And, and it could be also have been done by another trader. That's not the right answer to give. So unique idea is key. And then you have processes like the starter process. For example, when somebody joins the company and gets some initial rights and the initial rights for a person who joins the company should be derived from the profile of the department. He works in. So you got like a role description, okay. He's trader in this, in that area. And with that, he should have these rights and then you've got the blueprint and then you give this person the associated rights with the re-certification. We can check that the persons in the system are still correct. So we have validated the list and with a mover process, we make sure that when a person moves from department a to a department B that this person gets the access rights revoked in the one system and gets the new access rights in the other system.
That sounds again, pretty simple is again, practically speaking, very difficult, because what you will experience is that once a person wants to change, then the line manager, the old line manager says, yeah, but the person must keep the rights for another three months time because we have to do the handover. And he must also additionally have the new rights and the new systems. And maybe this course is a segregation of duty violation and it's impossible, but then we must have a strong mandate to say, no, we must revoke the rights right now. It's impossible for the same person to have this and that. Right? And this is something that we have to define in here. And then once the project has gone live, somebody has to operate it. So we've got at the moment, a team of five to six people operating user access management in the company.
And after long struggle and after long discussions and long debates and, and fights, we placed it in it. And to be honest, I was skeptical in the beginning. Many of us were skeptical in the beginning and I will probably also find in the audience, people who say it is that the right place. But look at our org chart, you could probably throw a dart on that org chart and no place would be the best place because we don't have an operational department yet, which would be the perfect fit on the other hand, I think now, and I can see it now, when it's working that user access management out of an, it can work as long as you have a strong mandate, that's the key. And we've got a diary reporting line into the CFO. So whenever something is going wrong and we have to shut down a person immediately, and it doesn't happen for whatever reason. And we've got resistance from the directors, we simply go to the CEO and say, okay, talk to your board colleagues. This is not acceptable. And fingers crossed so far. This has worked, as I said, the project is not an it project. So it budget was only around, about half of the budget used and the other half distributed between the cleanup activities for HR data, the setup of the processes, which was a quarter of the cost roundabout. And then the organizational implementation, which again, took some amount of the project budget of 2012 that we used.
So what does the team do today? What is user access management in practice by the operational team as it is today? As I said, in the beginning, we had seven requirements going in actually four functional requirements. You will find them here. Again, it all starts with the re-certification. What does it mean on a user level? You get lists of people in the system and you go to the user authorization controller, the nice bouncer in the beginning and say, okay, is this list of people in your system? Correct? Do you know all these people? And I've seen these males coming back from USCS, to me asking, who's this guy to know him or this guy has left the company, or this guy is not in the department anymore or whatever. And at that point in time, we are able to react. So this is the situation we are in today. We can react to those reports. It goes down to the number two, which is on an application role level. Again, the question, okay, now we know who's in the system. What access rights do the people have and should they have these access rights or should they work, or could they also work with less access rights? Again, I've seen those males. Yes, this person has access right. To change the curve data, but this person also has admin rights. Why? So we remote the revoke the access rights of administrative functions and just keep the other one.
Then we go to the top, to the bottom, right? To the number three, which is on an application role lever, where we make sure that the composition of a role does not create any segregation of duty issue in itself. So the roles must be clean. And this is also important to check that again, after every reorg, because the role definitions change with that, the people working in the department, the cuts change, and then you have to check it again. And when you put all the three together, the one, two, and the three together, then you are on the best level on the user level to make sure this person has this and that access right in that system. Plus another one in that system, plus another one in that system. And that all cannot cause any harm because the construction of everything that this person can have this and that, and that altogether is not creating any segregation of duty violation.
And I've deleted all the numbers, but just to show you what statistics you can expect from that. So that is over a four week period. I get biweekly reports, which statistically, for example, show me the number of EGC users to be confirmed. What does that mean? EGC OEM global commodities. There is a user in a system where we do not know should or should not this person be in that system. We need a confirmation from the UAC and some of the UACs react very promptly. Some other are lazy. So that means that this of course has to be go going down to zero. But as you can see in the report, it hasn't also, you see, for example, in the fourth column to be deactivated, we identified a person where we said this user has to be deactivated, but it hasn't happened yet. Again, this will be going down to zero.
So this is the initial phase where we see this is really going down and, and reducing the number of violations that we see. And we get all the eight systems green very soon. I'm pretty sure all the eight systems that we have connected in the last year, what did we learn from the project? So the project took like 11 months of time, roundabout, what were the basic learnings? And I was extremely happy yesterday. And I talked to one of the keynotes because when I found kind of these recommendations that we have learned also on his slide to say, what do you have to do, right? To really come to a working functional solution in user access management. And yes, it should be driven by the business. It should be driven by a central business function. It is not an it project, whatever the people tell you, whatever the CIO tells you, whatever anybody else tells you.
It's not an it project. It's a business project, vendor selection. I told you, we came down from a number of like 20 to six to two to one, and finally selected the one that was the best fit for the company. And that was also what I told my CFO. He said, okay, we've got corporate it cars. And can you look into aligning with them and maybe choosing the solution that they have in place? I said, I will go there. I will check. I will align. And then I will select the solution that solves the problems of Aon energy trading, because we are special. We have a special business and we need a special solution. So select the solution that suits your needs first. And for all, you have to know what you want, but once you know it, you can select the right solution.
Well, time schedule sounds simple, but goes in line with the old project saying a lost day in the beginning of the project is exactly as painful as a lost day at the very end of the project. So being exactly sure what you're aiming for and that you can fulfill it. Of course, afterwards is always a bit too slow and it could have been done two months earlier with a bit more results and a bit more requirements aim for what is possible, but be careful about the timing and the stuffing and very important. The internal knowledge build up internal knowledge, use your internal knowledge because only you can define what in your company should be allowed or should not be allowed. Take the responsibility and build that up with internals quick outlook into the next phase, which is planned for 2013. So for this year, you see a big gap.
We haven't done much until may. Why not? Because we have just merged with the business of Aon Rugers with the long term guest contracts of I rugs and well, we have just merged as a bit enthusiastic because there's a big cultural clash. You must imagine. I showed you in the beginning, the picture, the traders in disor, fancy place, people from 40 nations, 40 nationalities. And then you have this old traditional rugs, which is founded in essence in the sixties, and it's pretty German, pretty hierarchical. And, and so the structure and complexity of this two cultures will cause a cultural clash and it will take us at least two to three years. And that's optimistic as two to three years to join the cultures here. But the first and most important step is that the RO people are now on board. They are, and just of the car park is full.
That took us till may. That is why we didn't do anything in the car system until may, because we had to anyway, look to the results of the last phase and get the cleanup done. But for the rest of the year, we are planning to connect again, another like 12 systems, 12 more systems. And with that, we will continue to grow and we will go to the next version of the software and we will ease up some things and we will not finish. It's never finished. What other challenges ahead? So basically this is around the domain knowledge build on what we have extend the domain knowledge, learn about your duties, learn about your things merging business. As I said, two to three years time, at least to combine and merge the businesses that we see over the short term trading and the long term contracts in the gas business that we now see together. Transition of it. Very interesting point. I just mentioned it here very briefly. But as I said, as a, as Aon, as a whole with 70,000 people, we have a corporate it of 3000 people. The exception of the rule is the trading business with 1,500 people having their own it with around about 150 200 people. But this will change from the 1st of January, 2014, the it of energy trading or global commodities shall move over into eon it, corporate it, and that will create challenges of its own.
And then at some point in time, and that is more visionary. We will see that we have to go from a reactive solution, which we see to a proactive solution, which means at the moment, we are looking into a list of the guests of the club and say, okay, these people are in, oh no, they shouldn't be in, throw him out. We must come to a stage where we say we prevent that person from coming in to have a real doorman who prevents before the person even gets access to prevent this person from getting access. But that's not for 2013, maybe not even for 2014, maybe this takes longer. So I would say altogether, this is for me. And before I open my before one or two minutes of questions, I would simply close with the word that it's for us, a long road to go, which is at least as long as the road to Wembley. Thank you.
Thank you, Carsten, by the way, I like the colors of your presentation, more red than yellow. Are there any questions we come over to you
Which group within your organization actually creates the accounts in those systems that and the entitlements for those accounts?
So, first of all, maybe we, we can split that in. And then this is the split I didn't mention in particular. So we start actually with identity and access management. So the ideas and identities are created by corporate it, so there's an it solution around identity management in that, and this is all done. Identities are created by service line. And so on. Once we have that identity, then there is a like five step approach to really create the entitlements in the system. So that is done by specific teams in the systems where the order goes from, okay, create these entitlements for this. And that person goes through an order team to an application management team and then to specialists of that specific system. So when I mentioned eight critical systems, we have eight critical systems, like the most crucial trading systems that we have. And we have a special team for the endo that we have, which is able to create really the entitlement and the role and the setup for that specific person.
So it's not that user management team. I take it
That, no, that is, that is not yet the case. So when you look into that provisioning and recreation and so on that, it's not yet with the user management team. So that is distributed. Yeah. And in conjunction that the user management team of course has discussions with the specific teams to exactly do that.
And for the re-certification, do you involve the line manager as well? The supervisor of the person in that process? That was my
Question. So we have actually two, two permissions that that has to be granted. So for example, if you look at a person, then you have his line manager and in the beginning that person says, okay, I want these access rights and has then a, a signature of the line manager. Yes. My member of the team should have these access rights, but then it goes over to the user authorization controller because he is then the owner of the rights of the system and says, okay, this guy wants the, this guy wants these rights. His line manager says, yes, but I say no. Or I say yes. And the user authorization controller is the one that checks the re-certification list in the end. So he's the ultimate responsible person for the re-certification list.
Carson, thank you very much. Okay. Was an interesting presentation and join me in giving Carson. If you can,
Thank you very much.