So I will hand over to Dr. Kuman from, for the first presentation, and then we get another presentation from somebody from Everett. Yeah. So I have to from Atwin oval who stands in for jail course who can't make, who couldn't make it. Right. All right. So over to you. Yeah.
Thank you very much. Yeah. As you, as you can see, I would like to talk a little bit about the relation between business and it, and I think in the first two use cases that we very interesting use cases from the banks that we saw after lunch, we could already hear something about the relation between business and it, when I reviewed my title here, I realized that maybe this already this title, how successfully get business to participate in IM and access governance tends a little bit too well to, to raise a feeling of blaming of the business already. So, and exactly, that's what I did not intend to do. So I think maybe I should rephrase or refine the title a little bit and say how I am and access governance projects can benefit from a good collaboration of stakeholders, because I think the art of collaboration, that's principally a very big part of the success of identity and access management and governance projects.
So let me start with some things with some good intentions, which not necessarily lead to big results. For example, what I see sometimes when I get as a solution provider to companies, I get the mood of it who say, okay, we are trying to automate some things and Hey, let's do some workflows as well. Dear business, don't worry. We make something nice for you. And then they start up and when they are halfway done, they start to include the business in what they are doing. And I think that's absolutely not working. And of course, in the first presentation towards the business, they start from scratch. Again. Second opinion business saying, well, procedures are so difficult with it. If we want to get the report, we need to go 3, 4, 5 steps. We need to call people. We don't, we get some reports, but we don't understand these reports. So it doesn't help us. We need to start on our own. So obviously doesn't work as well. Some other things like security people saying, well, the business guys, they're doing whatever they want. We need to take care of this and we need to set the limits
Or it risk manager. Well, I have a audit remark. I need a solution and fast, we can make fast solutions, of course. But if you just go and say, well, give it some tools, they will do something won't work as well.
So one key thing is get everybody who is really responsible to the table. And I think you can only bring people to the table if you show them the benefit they have. For example, in one of the banking use cases from Mr. FSK, I think we, we heard that saving of accounts, license savings is great motivation for people to buy into such a project. Other things like no disruption at work, no struggle with help desk. You know, people are calling help desk and, and they wanna get rid of this. So if you give them a workflow tool, which makes life easier for them, they will buy into this. If the risk manager doesn't get, get more audit remarks he will buy into this is if risk under control. Very good. So benefit, I think is a very key thing. Key aspect to get people at the table.
Then of course you should understand who can contribute what, and also who can not contribute. For example, if you say, okay, I want to start small. I want to focus on a certain business area where maybe for example, governance or provisioning processes are already kind of nicely defined. The guys in this business unit have really developed some good things. Okay. Then maybe you should focus on this first and get the other people, get the other departments to the table at a later point in time. Another thing is the mode of collaboration who should be participating in which workshops in which concepts. And another key thing is how can people be convinced to accept their responsibilities has a little bit to do with the first aspect, the, the benefits aspect. Of course, it's, it's a pain to take over responsibility, but on the other hand, if you take over responsibility, then you might have the benefit, for example, that you don't have any more audit remarks that you are in control. So it's a positive thing. And last but not least, you should not avoid conflicts, but you should really discuss them when people are on the, at the table. For example, if system owners think with this more global approach, they, they will lose some of their realm. You should discuss it with them and you should show them the benefits that they get.
Well, I would like to talk a little bit about some successful collaboration in some selective areas. First of all, in the area of the other identity and governance data models. So to say, so looking at accounts, access rights roles, secondly, in, in the area of policies, policies, meaning things like external internal regulations, also it policies also provisioning policies and thirdly, in the area of identity and access governance processes. So if you look at accounts access, right, and roads, it's, it's, it's a kind of full data model. So to say, which includes business terminology, and also it terminology, which covers the whole stack, which includes access policies like who should get what, or like, you know, ma risk restrictions or ma risk policies. So business level policies contains role models contains if you, if we talk about role models contains also things like providing to the business, the right notion of roles, which they really can work with.
On the other hand, technical items like accounts, entitlements, technical policies, things like going down to well SAP transactions and, and such things or SharePoint, permission levels. So going the whole range. And if you look at this, how can you bring business in it together? So what you, what you realize is business people know what they want. It knows what they get. So there is always somebody in between who does the kind of translation. So for example, there are it coordinators. People come to them and say, well, I need this and that. And then these guys have in their heads, they have the intelligence. So to say, to bring the right resources to them. So you have to work on this and you have to bring business people, the, the interface people between business and it, and the it people together in order to put all this intelligence into your identity and access governance system. And only when you do this, you can really provide the right information of the business people. So the business people get an, a kind of abstraction layer information, which they can use, which they can really relate to. On the other side, only if you have agreements between the, all these parties, they can be sure that, that if they accept things, if they, for example, re-certify things that has the right effect on the it side.
So it's,
It's the art of finding on the one hand side of business language for a role model and for access policies and relating it to the technical language for accounts entitlements. Some sometimes it's very simple. If you, for example, have in your company, if you have 80 groups which have a naming convention, which business people can relate to, this can be a very easy task. If you have like insurance or banking applications with a very technical security model, it's a difficult approach, or it's a difficult task to create an abstraction layer to which business people really can relate. Next thing set up of policy and management of policy. So if you, if we talk about policies, it's about defining a strategy, defining also, or selecting analytical tools. For example, if you have a strategy and you say, okay, I want to control. I want to set up my policies. And I want to see is my environment really in line with my policies, then you need to have some analytical tools. You have to do the analysis. You have to interpret your results. You have to clean and consolidate. You have to establish a permanent audit process. And maybe you also have some, some automation, for example, provisioning tools. So of course in,
When you look at strategy, when you look at interpretation at permanent audit, and of course also when you talk about automation policies, then the business is very much involved and it can deliver the analytical tools can do the analysis, can do the cleaning. So how can you really have a focus on, on the business here? So I think business it's clear that business needs to continue doing business. So that's clear. So business will always not be happy if they are bothered by, you know, policy projects. So first thing is focus on the most important business compliance regulations. It's very difficult to do a really big policy project that involves a lot of business people. That doesn't mean that you don't do a strategy, but it means that you start small when you really do things. If you have it related policies, for example, no account should be without a person, as an owner. Then of course, you can add this as a kind of, from an it perspective.
It's not necessary to bother business with this next thing you could do. You, you should try to do of course, as much as possible in the central team, of course, in a mixed team, consisting of business people and it people, but in a central team so that you don't bother the department managers too much. You should look at tool support during analysis and interpretation phase, for example, using recertification tools, which make it much simpler for the business to respond to your requirements. So they don't need to fill out big sheets of paper or big Excel sheets, but they just have a recertification tool, which they can handle very easily. And which also can very easily control, for example, the progress of such certification processes and another suggestion. For example, if you have an automated provisioning in place and you want to do things like re-certification of your policies, then you can, on the one hand side, of course, look at the review, the provisioning automation rules, but you can restrict your recertification, your reification of each access, right to the manually granted permissions, which takes a lot of load away from the business users.
So in the last item I wanted to highlight is the, the, the process aspect. So of course, again, when you look at access management processes, you have a business aspect and you have it aspects. And of course the business knows the, the pains they have. They know that they have to call it coordinators three times a day and that they don't wanna do this anymore. And they have to fill out very complex forms, et cetera. They know they also know the user acceptance criteria. They know when users are happy with which kind of user interfaces users are happy. They know the business processes. So it, people often think they know all the business processes, but they don't. On the other hand side business, people think they have thoroughly defined their business processes, which they usually don't. So in this aspect, they can help one another.
So, and the business of course knows the business owners should know the business owners. So this is in some companies, of course, this is very well possible in other companies. Business ownerships are very difficult of course, to determine on the other hand, it knows the execution procedures. So how to provision data, how to pull data out of it systems and how to present data, present information to the business people. And they know how to precisely define implementation, ready processes, and they know the tooling and the features so they can guide the business in terms of using standard products for fulfilling business needs.
So that means there is a fruitful collaboration possible. That means if they collaborate, they get clean, automated audible end to end processes, they get a standard space solution. They get tasks that are appropriately assigned in the appropriate business language for the business. They get acceptance by the end user. And we see that this, this is a really a very important thing. If you are, if you do a identity and access governance project to really do an or reserve sufficient time for an end user acceptance, and finally to address really the pain of the business and to create value.
Yeah, my last slide, just very small story, because I think that's a little bit characteristic for, for some, or for many, many projects. So recently I read a small story about a student who was studying agriculture and he was developing together with his student team new methods for agriculture and wrote a book about agriculture. And then they go out and sell this book and try to sell their methods. And they go to, to the farmers and he's going to a farmer and the farmers at work and, and the farmer says, and, and the students says, well, we have these new books and we have these new methods for, for, for agriculture. And then the, the farmer says, son, I don't farm as half as good as I already know. So that means you should get advice. But if you got advice, don't start chaotic. Use this. Thanks.
Do you need to press something?
You saved the question at the end, after you have a presentation,
Right?
Is the presentation there?
Yeah. The 14. 14,
Yes.
Okay.
I would like to add on to the previous present station a little bit. I feel that's breast station here pretty much sorry. Discussed on why and what, on what levels? The collaboration between business and it needs to be. I would like to approach the subject from the perspective of a system integrator for the system integration company, where typically we get projects and assignments go in, this is what you have to do and go out. And in that context, the challenges of evolving based a little bit different. And that's the insight I would like to share with you guys, for people who don't know Everett, I'll try to spend 30 seconds on the slide. Basically, we are an identity in access governance and management consulting and system integration firm. And last year or three, we have done a lot of work on improving our project methodology, particularly involving the business. And mostly because we didn't do it and we failed not doing the right involvement.
So if you look at the last few years, identity access, governance projects have been, or maybe even identity management projects. As we called it a few years ago, have become more business driven. Or at least the budget holders were more on the business side than purely it driven projects where we got the assignment still from the it department. But somewhere in the back of the company was a business owner who was driving the project, which typically we didn't talk to. So even at this time, access governance projects are still driven by it, departments with it, tooling to solve a problem. And what we see is that typically there's a list of requirements, maybe lists of policies, and then it becomes it project. We go in, we try to do what is on paper. We should do. Then a business project takes over, tries to implement it into the organization.
And then they find out this is not what they need or not what they want. And we have to start all over again if we even get it far, because there's a bigger risk that after you work on the project for maybe three months or six months, and they see nothing happening, they're like, go like, Hey, where's all this money going, we're hiring this, this integrator. The only thing we, we, the only thing we see is a steady stream of invoices and now results. So one statements I would like to make is even business knows roughly what they want or where the pain is, and they know their problem and they know what kind of solution they want. They only really know what they want after have. They've gotten what they've gotten and they see, oh, this is what I ask for. I don't want this. And my, our statement is, and that's basically my final slide as well.
We need, if, if you take a project approach where you get integrator or consulting firm involved during the project for you, you need to run it in agile lean way with business product ownership. This means that you need to get somebody from the business as the driver's seat on the project have iterative stakeholder involvement. So don't wait till you don't wait till you have everything in place before you show something, show things, as soon as you get it, do just time to sign. Don't spend months or weeks making great lists of policies and great list of role models and everything, and get what you can as soon as you can and get it in place and get it running and get it used. So, one of the things we wanna, one of the things you make is release early release often and release smartly. Think about what kind of quick wins can we get into the company? What kind of process can we get in place, which are not, which are non disruptive, preferably even really help the business business to create some bursts, create some excitement and to make everybody in the client, in this case, the end user, a champion,
In order to do that, you have to pick an architecture that works something, something you can work quickly with, and also have to pick technology that enables this approach. And to do that, we involve, we created our approach methodology involved, which is agilely way time are any questions.
So thank
You, Edwin. And also thank you Martin questions there, questions to one of each I come over,
Hello, stay from Lynn. You, I, I understand this is the way to do it. How do you get the organization to accept this way? Because I, I, we are in the same work. I know the problem that it's the acceptance. How do you get the stakeholders involved and how do you get an standard? How do you say over processized it organization to act this way?
That's, that's a good question. It does. We try to do it, of course, during the commercial cycle where we really push our approach, but still you only push the approach to the person buying the project and still not implemented. And it, it is kind of difficult, but in one reached example, we weren't allowed to do this. And after I think, two months after seeing, okay, this is not really working, we were allowed to, to change the rounds, but typically yeah, contract management and sales. So make sure they understand the value, sell the value, sell the approach. I mean, we got a big white paper on it, on how to do it. And then we start, usually in this process, we start with workshops on methodology. So the first week we, we talk to all the people who are involved in the project, like the product owner, but also to stakeholders, system owners, business process owners, to explain how it's gonna work.
And actually, if you, if you show 'em the benefits, it's not really a big issue because if, if a business owners, Hey, instead of having to write a 30 page document or policies and, and procedures and requirements, and also waiting six months to see what it's gonna be, I only have to give a little bit of information every time when I have time for it. And I can see the results right away and start using it right away. If you can convince the clients of those benefits, it's pretty easy to be honest. And the other thing is asking questions. Most of these clients have done projects, and this is excess confidence, but this problem happens in many, many more projects, in many, many different areas. And they've seen the failure, they've seen the failures, they've seen how it's can go wrong. And they ask the question, how it's gonna go grow wrong. They say, Hey, this is maybe something we can try.
Can I ask something? Sure. Maybe two comments from my side. I mean, first of all, get people on board. I mean, either you have to tell them, you have to, or you have to show them the benefits. I mean, that's how it is. And of course the, the nicest thing is if you can show the benefits, sometimes you have to say, well, you have to, of course, one thing I like from, from talk is this, this idea of show and try, I think that's, that's really a very good, good idea. And we've been successful with that as well, many times. So if you make a kind of prototype, of course, you have to discuss, do you want, do you want to just make a pilot, which you, which you want to reuse, or do you want to set up, you know, kind of prototype that you throw away afterwards that you do with, with very low effort, but if you can then invite the business people and just show them, Hey, that's how it could look like if you buy in, I think that's what they really are fond
Of.
Yeah. Although we prefer, of course, in the show and try model to always get a real working solution, the real production, which is an ideal, ideal scenario, which doesn't always work, but pilots are dangerous because they are usually an ideal situation with ideal data. And so I really like to go for a full blown first phase in weeks and not months or years,
I don't see further questions around there's one.
So my question is, what do you mean exactly? Just in time design? Is this more organizational? Is this more technical? Is it mixed? How does it look like?
Well, both, I would say the basic premise there is that there's a huge risk. There's, there's two approaches. The one that's called BD F big design front. And the other approach is Git just in time design.
Our statement is if you take a lot of time designing stuff and each stuff, you don't stuff based on stuff you've just designed after six months, when your design is finished, the design you made in the first month is already obsolete. And also you have to take so much baggage in your head, in your head about, okay. I thought I design this way or this way, and I have to take into account, but just designing the part you're gonna build next, designing the next policy, designing the next rule, designing the next connector. I, whether it's technical or business design build, test, deploy, run, try really going to cycles instead of doing big designs. That's what I mean. Anything
There seem to be no further questions. Thanks again, for, to, to both of you, to you Martin and you admin for presentation, please give everybody a big hand.
