ITIL Principles and Rapid Incident Management in an Investment Bank at SKILup Days 2024

Good day, good afternoon, wherever you are. My name's Robert Edward Pennington, uh, and I'm, I'm an I ambassador, uh, and I've been involved with it l since the early two thousands. Um, I've gone through, um, quite a few, uh, of the different, uh, upgrades of it l uh, from version two onwards.

Um, and I'm here today to talk to you a little bit about IT, principles and rapid incident management in an investment bank. Um, so just to give you a, a brief overview of what I'm gonna be doing, uh, what I'm gonna tell you about is the, I'm gonna explain what the situation is, what our problem that we had on the trading floor was and how we solved it, and how that ties in with the guiding principles of IO Some of you may know, uh, the view there, that's actually a, a view of Frankfurt. So you can guess that I was actually in the, uh, investment banking industry in Frankfurt, in Germany, and I worked for a very large, um, investment, uh, bank where we had a, uh, 500 person trading floor.

There's a view of part of the trading floor there. Uh, you'll see some of those traders there. They've got four, um, two rows of four screens, so eight screens each.

There are, there were others that actually had 12 screens each. So, and with that, they had, um, three, uh, iPad works stations. So there was an awful lot of applications, an awful lot of calculations.

It was very, very intense work there. Um, and we, uh, were situated. We had, uh, 10 to 15 people, uh, sitting on the trading floor.

And we had a service desk that was stationed somewhere else. The service desk dealt with, um, around, uh, 8,000 users overall. Uh, we had a, um, for the whole of the investment bank, but we did have a, a specific group for the service desk that we trained up to deal with our wonderful traders.

I dunno whether any of you've ever come across an investment banking trader, but, uh, they're not known for their patients, uh, and then not known for their calmness. Um, one time, one of the, uh, traders actually came up to me when I was explaining the issue to, to him and, uh, stood directly in front of me. I'm not very tall.

I'm like five foot seven. He was six foot two, and he was looking down at me. He was a very well built bloke, and it was, I had to look up and say, you know, Lars, you, you don't need to do that to me.

It's not exactly gonna fight in me. Uh, but you get the, the idea here that, that these guys, they weren't very patient. What they, when they wanted something fixed, they wanted it fixed.

Now, so that this brought me to, brings us to the problem. Uh, we had a, a 15 minute response time and a 60 minute solution time in our service level agreement. Well, this meant was if a, if a trader found out the service desk, we had 15 minutes to get the ticket recorded, classified, and sent to the second level support and get that second level support person who is sitting midway on this trading floor, which, as I say, is about the size of two football pitches to a trader, uh, who had the problem.

The trader's location was easily identified by the row and seat numbers. Um, but on the way there, the, uh, the second level support guy would often get stopped, Hey, hey, Joe, come over here, come and fix this issue. Sorry, out I've got, I'll go and deal with the first guy for first guy's problem.

So they do that, and then oftentimes they're on the way back, um, they would fix, uh, the, this guy who'd called them over while they're on the, on the, on the, uh, in the direction of going to the, the first guy. This is often a problem within, you know, with service desks, you have a bunch of, um, uh, special individuals like traders who don't really want to spend time calling people in order to get them to come and fix their problems. Uh, whereas from a management perspective, and you don't to justify the resources that we had on the trading floor, we needed to be called all the incidents.

It was a, it was quite a challenge. We had a bit of a conflict there because our second level support guys will be on the way to go and see somebody and not have time to stop and fix this guy who'd gone, Hey, Joe, come over here. So not only did we have the conflict between the traders and the second level support, we also had conflicts between the management levels.

You had the managers of the traders, and you had the managers of the, uh, uh, of the IT department who obviously they kept saying, well, you are not doing that many incidents. Why do you need so many people? The reason we needed so many people was because we weren't, um, recording as many incidents as though we were actually fixing.

We tried to get, uh, traders to actually recall the incident when we got to their desks. They really were interested in doing that. And so we needed to come up with a solution that would, um, make everybody happy.

And the solution, the solution came to me one evening in a restaurant when, uh, a, uh, when the wasup was actually taken, uh, my order, my, my, well, it was not just my order, my wife's order. So he had his handheld and he was actually entering the order, not on a a paper notepad, but on, uh, a digital device. I started talking to the restaurant.

He passed me on to, uh, um, uh, his manager. They passed me on to, uh, a couple of suppliers of these point of order devices. And if you, you, this would then and enable us to actually record incidents on the fly.

If you think about it, um, you've actually got a trading floor. It's just a set of desks. The orders, um, that the traders give you are to fix certain bits of software or their hardware.

So this sort of safe, satisfied both sides of the equation. We had a high, high quality of incident recording. We could capture all the incidents because my guy would just go up to the, the trader put in not table 15, but desk A one.

What's the issue? Or what's the order? No, it's not a soup.

He's got a screen issue. No, it's not. Uh, he doesn't wanna order beef.

He wants to, uh, he wants his, uh, Bloomberg terminal fixing he terminal times, because there was, we lack this conflict of can you be called an incident? No, I'm not gonna be called an incident. What are we gonna do?

And we got more accurate incident, uh, recording, and we actually captured all the incidents that were, uh, we were dealing with to, you know, just talk about some of the guiding principles of IS l and how we use those, uh, in order to, um, address this problem where, what, what we use from the is l guiding principles in order to fix the issue first. And, and and foremost was focusing on value. You need to know your stakeholders.

You need to know what matters to them. So they were, uh, they, they are our key stakeholders. These traders, they didn't really wanna do deal with filling up the service desk.

They didn't want to deal with, um, incidents in any way. But on, on the, the other side, we had our management who wanted to insist that, that, that the traders did this so that we had, we captured, um, the number of incidents we were actually dealing with. And so we could, we needed to work out how we could create that value, how we could address that conflict and that timing issue.

And the handheld actually became quite popular because it was just an easy way of recording the incident on the fly. So this brings me to another, it told principle, start where you are. Look at what your environment is like.

Don't focus on like functional fi uh, fixedness where you, you, you say, this device only does this, this way. Think of, you know, you have to think a little bit out of the box when you, you, you are looking in the start where you are. Um, and we can see, you know, once I've been in there and explain this to my colleagues and, and we, and I had this idea, a trading floor is just like a restaurant.

The traders, they're just like diners. The trading desks are the actual tables in the restaurant, and the incidents are, are, are the equivalent of orders, uh, that you, you that, that the diners want to place. And as long, so it, it made perfect sense to take one of these, um, devices from the, the, the very, very common in the restaurant business and just apply it to our trading floor so that we could then, uh, we'd change, um, the layout of the restaurant.

So we reflected the, the trading floor, we changed, um, the menus so that the, it, it reflected the sort of incidents, the common incidents we would have on a trading floor, such, such as like, you know, broken screens, broken software, broken computers, whatever it was. Uh, and, and we could take that and we could take the, uh, output from those devices and feed those directly into our incident management system. So it was a matter of seeing where we were and what we could do in order to fit in with recording the incidents in a more and more flexible way.

Another guiding principle is keep it simple. And because keeping it simple, simple solutions are the best. Don't over complicate.

When, when we, we started looking at the interface for this, um, uh, point of order with a lot of things that we could have done, but we kept it simple. We just, we used the, the basic, uh, technology there. We didn't over complicate it.

We didn't, um, change anything in terms of the interface in order to, to, uh, create incident tickets. We left the, the incident ticket format the same. And we, um, and we left the, the, the, uh, design on the, the point of sale device the same, the simply over a period of time, obviously we, we, um, progressed intuitively, which is another guiding principle, but fundamentally we start really simple and built on that in order to come up with a, uh, a solution that made everybody happy.

And so that, that brings me, uh, to the end of my presentation. Uh, I hope I've shown you how you can look at a tricky situation in an investment bank where there's an awful lot of conflict between, uh, all the different stakeholders, uh, at a low level and at a higher management level. And, and how you can use those IT principles by focusing on the value keeping things simple, um, uh, in order to address these problems.

Just a little bit of thinking outside the box and you can get to a solution that maybe Navi else has, uh, come up with and, uh, solve that problem.