Video Transcript
I think a lot of companies will benefit from having this type of information so that they can model what you've done at MUFG. I want to conclude by asking one other question, and that is around the heat maps and so on that you've worked with and being able to look at a heat map for a particular line of business and identify SLAs. Could you talk just a little bit about that and your partnership with Broadcom in developing that technology?
Yeah. So again, with around the SLA AI, it's a two-part process. From an SLA perspective, what we've done is within our SLA process, we identify SLAs or SLOs, depending on wherever it is, objectives versus SLAs. But the goal is to get the file processed on time. What we've done in that SLA process is include a lot of the trending and analytics information within the SLA documentation that gives that end user the ability to really take a look and say, "Okay, can I make my time? I need to make a 10 a.m. when you start looking at all the upstreams." We run all our analytics. We can actually, which was great, we had a major divestiture last year. We sold a big portion of our bank, and we had to understand the linkages between the applications so we could actually break them apart. We used AI to take a look at that upstream dependency mapping, which could go 25 levels high, 25 levels deep. It really gives you that good understanding of how an application is integrated with other systems.
So from an SLA perspective, very similar, we want to make sure that the upstreams that are feeding this core system are meeting their obligations as well. As part of our SLA process, we include these dependency mappings. When someone comes to us and says, "Okay, we need to make a 10 a.m. SLA," it's virtually impossible when the system above you is giving you data at 10:00. So we use that to drive a lot of that information. We built a lot of that into our SLA documentation process.
And getting to your point about the heat maps, what we've done is, using the tools, we run analytics every month. We know what our SLAs are, how many times a job runs per month, how many SLAs are associated with that SRA. So if a job runs one time a day, 20 days out of the month, it's 20 runs for the month. Some of them run multiple times per day. Now we have an idea of how well they're performing against those 20 SLAs that they need to make every month. What we'll do is by line of business, we'll just do a simple heat map or an analytics or a trend to say month over month, "Did you hit your SLAs for last month? You were 18 out of 20, which is okay." Whatever the number is, I'm not sure the exact number. But if you go below a 90% or 95%, depending on the line of business, they have their specific criteria that they need to meet, whether it's 90%, 95%, 99% on some of them that they have to meet a certain SLA. We'll actually show them that information within these heat maps, and they look month over month.
One month doesn't make a trend, but the nice thing is we show six months of trending, nine months of trending, and it'll show you your fluctuations, how well you're doing against your SLAs. Then we'll show month over month trending just to show how well you're doing from a previous month. We present these in these business meetings that we have on a monthly basis, and they are actually able to see at one shot how well their application and their business are performing and hitting their mark from a workload automation perspective. So pulling the data out of running the jobs out of Autosis, pulling the data out of AI, and then trending it and using these heat maps to generate these reports and sharing with the business has been paramount to our success.
.
![]()
|
Note: This transcript was generated with the assistance of an artificial intelligence language model. While we strive for accuracy and quality, please note that the transcription may not be entirely error-free. We recommend independently verifying the content and consulting with a product expert for specific advice or information. We do not assume any responsibility or liability for the use or interpretation of this content. |