Session Information:

Control your robots – Designing an effective RPA governance program

It’s easy to underestimate the work and time involved in satisfying the needs for RPA governance, whether your business complies with SOX or not. Marco Chmura, Director of Quality & Transformation at Morningstar will share their journey in building effective controls as they’ve continued to expand their program (now in year 3) to key processes interacting with SOX sensitive applications.

Some highlights: 

• What does success look like and what’s needed to achieve it?

• Partnering early on with Compliance & IT/Security teams on:

• Security Administration needs

• Establishing Change Management & Appropriate segregation of duties

• Fulfilling Backup and Recovery requirements

• Identifying and empowering a core process review team

• Controls in place, SOX sign-off received – What’s next for RPA program?

Session Transcript:

Welcome back to RPA live with the RPA and Intelligent automation, that Paris Global Excellence Innovation Leader, and your host. I'm really excited about our next session. We're going to have a global leader, in the area of RPA, sharing very practical program implementation, and governance steps, for a very large, well-known financial services organization. Further ado, our next session is Control Your Robots, Designing an Effective RPA Governance Program. I'm thrilled to welcome Margaret Shimura, he is the Director of Quality and Transformation, a Morningstar. He has served the company for just over 12 years. He's responsible for driving transformation initiatives across the organization. spatially, to help shape and implement RPA and other automation, as well as enhance the impact of Morningstar's Research.

Marko, Great to have you here. Thank you for sharing your presentation today.

Great, thank you, Josie.

And good morning, good afternoon, and good evening to all the various attendees. I'm very excited to be here, to be able to share some best practices with you all. I've had the pleasure to attend some of the previous sessions and, and I've loved the commentary so far. So I hope to keep that going.

So today I'm going to give some background on our RPA program at morningstar. I'll talk about some of our current areas of focus. But then I also want to give a story around our governance, and how that's evolved since we've started practicing RPA. Why, we've moved forward with a more focused program, how that's going to help us. I'll give an overview of the controls. I'll try to make it as exciting as possible and I'll even share a process example when I do that. And, I'd like to share just some key learnings. Wherever you are in your journey and hopefully you can take away some of the learnings that we've gained as we've gone through this process because it was relatively new for us. And then I'll close with what's, what's next for our program, how this will help us and then we can jump to the traditional Q&A.

But as Josie mentioned, I am a continuous improvement leader at morningstar. I have been practicing coaching and training some variation of Lean and six Sigma. For the past 20 odd years, specifically at morningstar, it's been great to work with so many various business units to help facilitate the adoption of lean concepts and tools. As they seek to improve themselves, become more client focused and data driven. And similar to a lot of us, it was really about four or so years ago that we started to take a more transformational focus within our internal quality team and start to focus more on future ways of working and adopting new and emerging technologies, like RPA.

So we can focus on automation and grow with what we, with what we currently have. So as, as you probably gathered, our quality team is responsible for facilitating the adoption of RPA at morningstar. I had the pleasure to watch Tony's Blueprint presentation yesterday, which was great. It gave a nice kind of overview of what he's seeing at the company. So now you can hear a little bit more personal perspective, and the dialog that he had with Josie At the end, where he talked about you know, where Continuous Improvement and RPA intersex.

we're, kind of an example of that, because our connection with the business, or connection with, the teams are focused on adopting new tools really made it ideal for us to set up the RPE program.

So, before I move forward, just a little bit more about Morningstar, for those of you that are not familiar, as Josie said, this is, we are an investment research company. We have over 6000 global employees, were based out of the Chicago headquarters. Those employees are responsible for building and delivering our great data and research across a variety of platforms, so Web base, desktop, APIs, data feeds, the like. As you can imagine, like a lot of us, there are a significant amount of processes that go into managing all of that across the business.

Sort of focus on automation can really help us manage the litany of custom processes, We've done a lot of acquisitions over the years, so as we've tried to integrate other companies in their processes, into our, our way of working, there's been a lot of opportunity to Turk. There's been a lot of build-up of some of those custom processes and new processes and, and processes that are kind of a slight variation of, of what they should be. So, you know, where they've gotten a little bit out of hand, we really saw a good opportunity for automation.

So we started experimenting with RPA late in 2017, just started piling it with a few key processes. Just to see it, have some success, which it did. We, we've partnered with a few vendors in the beginning, just to try it out. But we really got started in the beginning of 2018. So here's, here's some numbers to run through real fast, just to give you some perspective on our program. Like Tony discussed yesterday, we are a centralized model after piloting it and seeing some success. We really saw centralizing development in a global COHE would be our best path forward considering we do have a lot of sensitive processes.

And we do have a kind of a desire to, we saw actually, an opportunity to have more dedication from developers so they could learn the tool better, you know, grow and upscale themselves. Also, a better opportunity from a cost perspective to leverage the licensing model from our vendor.

Currently, we have 10 RPA developers in our Global CEOs. They operate out of our Shenzhen China, and our Mumbai India Offices. We also have a dedicated RPA architect, who, actually, I'll talk about a little bit more because that gentlemen, who is also based out of our China office, has played a very key role in the documentation and the work involved in establishing the controls that I'm going to talk about today. We connect those developers with greater than 200 process owners at morningstar. Process owner is a role that's been fairly well established at the company given our previous efforts with Lean and our desire to really empower folks to focus on how they can manage a process, effectively, improve it, make it more.

Build more quality for our clients and users. And those process owners are really what drive the program, we really work through them. They are responsible for identifying the processes, of course, and then for a lot of the management, and even for participating in some of our controls that we've put in place, as we move the program forward.

And the final group I have listed here are, of course, our various tech and product owners across the company. There's a lot of different technology teams that own and manage the applications that we're working to automate. And connecting with them, and working with them, to establish the right level of access for the bots, to ensure that they understand how the bots are going to be accessing their system, and that they're kind of partnering with us, as we need to make any further tweaks and onboarding going forward.

We're a UI path shop. So we started with UI path. We were very happy with their onboarding with their support model. And we're currently in year three, as I mentioned, and we're at about 25 bots overall. A majority of our processes, probably, like most of you are on attended. You know, there's really a desire to fully automate, but there's a good amount of use for putting through our attended bots as well. and some of these licenses will actually have to grow. I'm sure UI Path is happy about that, where we'll have to adopt some onboard. some new Bots, as we expand processes, as a result of, going live, with our controls, and governance program, and kind of opening up the doors to some more activity.

Just to comment, we're also experimenting with other areas of automation, for our PDF automation projects. We do have an Abbey flexi capture license, so that's actually something I'll talk about, because we had to incorporate that into our controls as well. We do have an internal chatbot. We experiment. We're leveraging Google Dialogflow for that, And really, just using it internally, and some structured Q and A search options, but really see a lot of future value, and having chat technology with our business. Of course, something self serve, and client facing would be the end game, but we're really not there yet. And experimenting with something kinda low risk. And internal, has been a great learning experience for us, and even connecting that chatbot with other automation tools.

Specifically RPA, but also, you know, as things advance, will be a huge win for us, too. So we're really looking forward to expanding there. And then and then finally, we do have data scientists at morningstar. We have a whole other program around advancing some of our machine learning capabilities building models that help us automate our data collection. Which we do quite a bit of, as you can imagine, being an investment research company, connecting with fund companies, and data providers all over the world, and seeing ways that we can leverage smarter automation, too.

Fully automate our data collection. So, a lot going on there today, I'm mainly going to be focusing on RPA, because I want to talk about governance. But, I want you to keep that in mind, that we're, you know, we're experimenting in many different ways, Just to kinda check in on where we're at with our process counts and how the program has evolved. We have greater than 450 processes automated, There are varying size, but they've been able to yield almost 65,000 or greater than 65,000 annualized hours saved.

So, know, we love the hours savings, We love to avoid future hours as well by leveraging RPA, But it's really our quality, it's really our quality gains and our ability to deliver a lot of this data more timely. To avoid any kind of inconsistencies when you're repeating manually, we've talked about that a lot. So, big wins there.

As I Move forward, I want to talk a little bit about where our current areas of focus are, and unlike all of us, we're looking to build our pipeline as the program's evolved.

Know, we've had a good amount of focus in certain areas and other areas we've kind of struggled a little bit and lagged. So, we talk a lot about low hanging fruit, and I think we still have, I know we still have a good amount of low hanging fruit in some of our other teams. So, especially within finance, HR, service, some of that is due to focus, but a lot of that is due to a lack of familiarity with RPA, a lack of comfort level.

So, there is a, you know, a good amount of opportunity there. And a big reason why our governance program has evolved a little bit more quickly lately. And another area of focus, of course, is addressing those tech and product owner concerns. And any holdups they have with granting access to the bots and being comfortable that we have the right roles and permissions identified being comfortable with our program. We really didn't even realize how much unawareness with RPA unfamiliarity and confusion around it there was, until we really started moving forward with this more thoroughly.

And with that said, with those two areas of focus in mind, really helps answer the question we had, which was, why establish controls and strict governance for RPA? And this was a question that we asked ourselves many times in it, and it did lead to some delays in the process that I'll go through.

But really, it boils down to, know, we realized that in order to leverage RPA for any key financial reporting process and anything involving sensitive data and applications, and we do need to comply with our socks regulation, you know, we are a public company and there are a number of financial regulations that were brought about with the sarbanes oxley Act. And so that's just a key piece of what we need to do in order to be able to help our finance. Our finance partners mainly, but even some other teams that, that touch these applications be more capable of using RPA going forward.

And then, of course, while minimal, addressing the risk of a unintended action being performed by the bot, you know, any unauthorized actions, making sure that, and I'll talk about this more, but just that, if there are unintended actions, do we have risk mitigation in place, and will our controls help us address those? And then finally, any security risks and any unauthorized employee access, that includes developers, admins, process owners, anyone interacting with the RPA, software and program.

So, I want to share a little bit about what the process was that we went through. I wish I would have had this in the beginning, because it would have been very helpful for me to kind of understand what we were going through. As you can see, we're kind of towards the end of our process now. And I'll kind of talk through this a little bit more. So, the first thing we had to do is really just go ahead and connect with the teams. Like I mentioned, we have a global center of excellence development group, but we have a very local internal audit team here in Chicago. So really just connecting with each other, Understanding. the journey we were about to go down to become officially sox compliant, taking our current governance program to the next level. And I'll talk about what that was. Our, our internal audit team was completely unfamiliar with RPA. So there was just a lot of educating, you know, similar to letting new teams know about what RPA is, is and what it can do. And we had to go a little deeper with the internal audit team, and talk about the backend a little bit more, so, really, several weeks and months of just kind of getting to know you.

Similarly, our team, being a continuous improvement team and even our development co was pretty unfamiliar with sox controls, even when I show them to you, they take a while to sink in. So I'll try to give us a little bit of a Cliff Notes version. But it is a complicated, kinda set of requirements to navigate through and really ensure that you've addressed them. So, a lot of connecting reviewing a lot of time building the new process. I'll get into what that entailed. But it was partnering with a lot of our IT Teams infrastructure teams, info security, to make sure that we had our security mechanisms in place. But also the third bullet you'll see there.

Building a very comprehensive and organized policies and procedures document that's currently and just shared a Word document. It will be finalized fares. It actually is in its final version, assuming we don't have to make any further adjustments. Which it will live on going, but just having a very detailed document that explains the RPA program, explains the features and also is very specific on what the controls are and what they'll do. So I'll actually short timeline, I cringe at our timeline. Because it's, it's currently, it's looking like it'll be about a year and a half for us to get off the ground. Which I'll go into in a little bit more. But it was really at the end of last year that we were able to submit that more formal documents and kinda set ourselves up for a official review by our internal audit compliance team.

And it took them quite a while to complete that review. As you can imagine, there are a number of circumstances that will impact a cross functional team to be able to focus on this. So, not all of this is working time. I wanted to give you the realistic view of how long this took us about. You know, there were a lot of kind of stops and holdups along the way, Especially this year with all the circumstances we're all going through. Our internal audit team also is very busy at the beginning of the year because that's when a lot of financial processes get audited with the year end. Work that's going on, so had to navigate, like a lot of cross functional team efforts through different folks schedules and, and, you know, some, some different lags. But overall, taking our time was very helpful and there was quite a bit that we had to work through. So it's, It's time well spent.

We are in the middle of reacting to the observations that the internal audit team gave us for our design before we can. And I think we have most of it dotted, so that's why we're really near the finish line here is is a very timely presentation, because it really should be at the end of this month, and into July, that we're actually able to sign off, that our controls are in place. And go live with some processes that we actually already have developed, and ready to go, And even more importantly, start opening up the gates to the new processes that we want to launch.

So the final two steps are going to be signing off, that we have our controls in place, which I'll walk through. But then ongoing, we're gonna, like, I mentioned, continue to manage and improve those controls. There's a lot of efficiencies, we can add, some things. We kinda had to stand up in a less than, optimal way. But we can, we can continue to iterate and then we'll have to react to the ongoing audits. I'll talk more about that but we've really just set up at this point, our framework.

The ongoing will be, you know, the random audits from our internal audit and compliance team to check that our controls are working, that we're abiding by the document and that we're all good.

OK, so a little text here, I'm gonna give a few variations of this but I really did want to give you guys a sense of what the controls are and what we did to address them. So they are bucketed into really three main groups. The first group is around security administration. And security administration really entails that user access and that includes, again, all the users involved in the RPA program that everyone has proper approval of their access in place. Which we definitely did not have in our first year plus of the program.

A periodic review of user access is performed. I, I did see a question, Do we have any RPA is in production today? And yes, we do, We have a number of RPA and production, I'll go back to that slide. But. But we have over 450 processes live already. This is more focused on the ones that touch more sensitive data, and I'll give an example of that in a minute. The second piece of Security Admin is having a periodic review of that access in place. Mainly quarterly. But even some of the checks are weekly. Addressing our password settings, making sure they comply to standards.

Making sure the administrators of RPA are properly limited in their ability to get access to things. How, how we control access to production data was a big topic that we needed to work through. And then, the final one is about just any generic accounts that are accessing our RPA instance and making sure that their passwords are, are in place and that they're changed regularly. So, just wanted to give a quick overview of what we did to address some of these. Again, I'm gonna, I'm gonna run through this in a little bit of a different way to, It, takes a little while to sink in, to let you guys understand this a little bit better. But, but, basically, for the first one, we leverage jira and Confluence! So, that's an application that we have at morningstar. And then we use that to build a nice ticketing application. We actually built a ticketing application at the very start of the program to manage request intake and even to manage which bots are in production ongoing, which ones need further enhancements. Who's the owner, who's the developer, and all that good information.

But we also had to build a new jira project to track the users separately and their approval. So, for those of you familiar with jira, it can be very good for that kind of layered approval metric mechanism.

The periodic review is actually something that we officially started with Q one, So we just finished our official quarterly review, but we actually started reviewing those users last year, as we got familiar with it. And basically, it's, you know, you can improve someone when they first get access. And some of you are probably familiar with this, from maybe some of the applications you have access to, if you are a financial services company. If not, you know, it's always good, even if you don't have to comply by these regulations, to have some understanding of who are your users and, and checking to make sure that they still need access ongoing. So we do have periodic checks in place now.

We bill closer monitoring of our passwords.

Making sure that, you know, in any of the applications the bot is accessing, we, of course, have passwords set up and monitored, but this is basically the passwords for the orchestrator we use for RPA. And the service accounts that we use, which I'll also talk about more. But we connect bought licenses with service accounts, which I'm sure is also a model that a lot of you use, which helps us track their actions more. So changing those service account passwords that the bot uses is also something we had to put in place.

In order to restrict access to the production data programs, we just had to put fire call IDs in place, which we didn't have. So ensuring that fire call IDs were in place for any access to production, especially as developers are working from home. Just making sure that production data is restricted and having that documented appropriately. And then finally, just managing those generic account passwords.

The second grouping is around change management. And this is a very, obviously important piece of the controls because it helps us manage that Devin testing are done in a non production environment. It also has a sign off mechanism in place so that any changes to the process are signed off and evidence of that sign off is retained. So that was something we really had to react to. And then finally, when changes are moved to production, this is a very common piece of controls. Having somewhat of a segregation of duties so a developer can't move a code to production, it has to be moved to production by somebody else. There is a caveat to that, which we had to take advantage of, which I'll talk about in a second. So, satisfying these controls, really just ensuring that we were operating in a non production environment.

We added a sign off requirement into that Jira application so that all process owners have to sign off that. They have tested the bot, what the bot is producing, how the bot is acting, and actually recorded evidence of that testing. You know, I've tested the bot. I've seen the application and the recording that in the jira ticket, So we have evidence of testing, and we know that testing has taken place. The developer cannot move a product to production a project to production until that happens. And for the final piece, because we move so many codes to production, it was a very inefficient to expect us to do that in a segregated way. So we now move code to production.

Uh, by having detective monitoring in place, we leverage Jenkins for that so that we can be sure that no, RPA project is moved to production without having a jira sign off ticket in place. So the developers can kill, still, kinda keep going through their day to day. They just have a check in place that make sure that they're not moving anything into production without oversight. The system will stop them, and that's a key control that we now have in place.

Then finally, availability of data, and this is just around the frequency and type of backups that we have, ensuring those backups are complete, and these are just the logs that get produced by RPA. So, there's really not too much sensitive information in there, but we still had to make sure we have our backups in place and that we have a restore process in case of disaster recovery. So I know that was a lot of text, but grouping those into those three sections hopefully helped you understand kind of the major areas we were working through. What I'd like to do next is actually walk through a typical straightforward process. that has socks implications, that we are currently work waiting to go live with and kind of see how that worked. So what this is is actually just a straightforward This is how we enter client contracts. And setup billing.

So, a very key financial process for the organization, very manual and repetitive, very ripe for automation, but still not yet launched live because we have to wait for the controls to be in place for us to do that. And, so hopefully this one will go live soon, but I just kinda like to walk you through the process quickly and what we did. So, first is just logging into Salesforce, opening, that billing form, logging into Oracle. Those are the two applications we use for this.

So there's, there's multi applications entering the contract information, submitting the contract information, and then there is a control in place here, that is, validate or review. So this is all pre RPA, right. These are all steps that are happening before we had RPA available. And these seven steps are really what, what the process owner was responsible for managing and making sure we're in.

We're in a good state, then that brings us to the process owner, connecting with the RPA doubt developer. And introducing the finance bot to this process owner and seeing how they could automate the process. So I'll just walk through what the finance bought was able to do. So, the finance spot now, logs in. It handles the billing form. It logs into Oracle, It takes care of the data entry. It even does the user submission now. So a lot of these steps, and you can imagine, with a significant number of contracts, this is going to be a, a very, very beneficial process for the team. What I'd like to do next is just briefly walk through what some of the controls are in place that would impact that process. So going back through our groupings before, from a security admin standpoint, our developer bot and process owner now have all their access reviewed initially, and quarterly, any passwords. They're using comply with corporate standards.

And I think I breezed over this before but we've also uploaded all of our source code to Stash. now. We were previously storing all of our source code and SharePoint. But having it in stache now really gives us the opportunity to do security reviews and makes sure that the source code is restricted.

The second grouping is change management. Like I said, we now have detected monitoring in place. So once that process owner first goes live with this project, as well as any changes they made to the project ongoing, there's going to have to be that testing evidence in place and sign off before the developer actually goes to production. And then, the final piece is just availability of data.

So, all the work the developer is doing for this is properly stored and backed up in our DR instance. Next, what I want to talk about is, I kinda just walked through the checklist, and some of the important items, and sign off things that we have to do in order to manage that process. What's, very key, is, having a governance committee, on each team, within a continuous, improved prudent program really helping the teams manage their own improvement efforts, is our approach at morningstar. And we're very similar, and in helping business leaders, and their teams manage their automation efforts. And when it comes to some of these more sensitive teams, like finance, HR, having governance committees in place. They know their processes. They know their risks. They know how to mitigate them, is, is a really great way to firmly establish governance within your program, so you have your controls, but you also have your review teams, and we have our set up now, and we even have internal audit participating in this.

And, and what they do is they take every process that is identified as sensitive, touching a sox application or impacting controls, and then, you know, the determination of what gets flagged for certain other teams can maybe vary. But it's very important that those specific processes get reviewed. And here's a series of questions that they ask themselves. And I'm going to relate these questions back to the process that we just went through. So: Does the thought process require access to a sock system? So in this case, for those of you unfamiliar, a sock system would be Oracle, or even Salesforce because they help us manage our contracts and our money flow and they impact our financials. So that's a yes, is it performing a piece of the key control? So actually, that's interesting.

because originally with this process, the team actually wanted to automate everything, but it was actually paused at the validator review because that is a key control, so you can have the bot doing its work and doing the approval at the same time. Because then we would be in violation. So that's an example of where having a review, an SOP review committee and sign off from leaders is so key in making sure that everyone is comfortable with your governance program. It's not just like, checking the box. It's also about the conversations, the collaboration, and the discussions that need to happen. There is some flexibility in how we do things, so we have to be clear that everyone's giving their input. And then, a few of the final questions are around reviewing it for accuracy, having a good testing approach, and even understanding which bots are going to be performing, which activities. Again, if there is an approval process that isn't part of a sox control, you can have the bot do it.

But it might not be the same bot as the one doing the work, just to make sure that, you know, we're treating the bots like humans, and that's really a question that, that this committee asked themselves, don't give the bot access that we wouldn't give a normal person. So that's a good question to kind of keep in mind.

So now I want to just run through some of the key learnings as we've advanced the program. I touched on some of these already, but as much as possible, depending on where you are in the life of your program, you want to start shrinking controls early.

Like this conference, unlike any RPA program, governance and controls aren't the most exciting topic, You know, we jumped into our RPA program and really jumped into marketing and setting up the kind of mechanisms for requesting and going live and documenting SLPs and whatnot. But governance was kind of in the back of our minds. So the more we thought about it early on, the more people brought it up, the better off we were, but we still kind of had to do some catch up, and that was definitely a key learning. We decided decentralized development early. I don't know. I definitely believe that we can eventually go to a federated model. Ideally, we have employee, regular employees using our bots, but for now, are definitely not comfortable with that. So, having development centralized and controlled by one team, and managing the relationship with the vendor, will be huge for your program. Talk governance from the outset, set realistic expectations.

It's going to take awhile, so don't, don't expect it to be a quick and easy thing and, and make sure that everyone's on board with the approach. Leverages the experience and knowledge that's already in your organization.

It's a, you know, it's a very established, a lot of times governance, whether you're a financial services company or not, is being done by another software as a service team, so you can learn from them, connect with them, and understand what they have in place, and, and maybe even replicate. And then, you can maybe figure out what can be, in turn, achieved internally without going outside. You know, we talked with PWC about some of their help. They could give us from a consultant perspective to help establish our controls. But, you know, we determined early on that we could probably figure out how to do this ourselves, for now. And so far, it's gone well. So, you know, having those conversations, and talking to people in your organization can be very helpful. Ensuring ownership and commitment. I talked about having an RPA architect in place that controls the documentation that's dedicated to this effort, and really can help over, see, applying the controls to the team.

You know, again, by doing this ourselves, that RPA architect has a very close connection with the developers. So, as we implemented these controls, it was very quick and easy to explain a lot of that, to the, to the group, and get it in place, And then the teams need to own their prioritization, review, and sign off, build. Those governance committees, make sure they're in place. It's been a huge help for us. On the final one is important, avoid control and documentation overload. We don't, we, we tried to avoid being too strict. We have a 20 plus page documents, so there's gonna be a lot of language in there that we have to abide by each time we do one of our quarterly reviews. And whenever we're audited, they're going to be looking for very specific things or wherever we could make the language as generic as possible, we tried. And that's something we're going to keep trying to do. And certain controls and frequencies don't need to be as strict as maybe they're intended.

So for example, checking terminated users at the company. They can't access RPA because they can't access our network, but we were asked to put a double check in place to verify that users of RPA are still in the company. So there's a little debate on how often and frequent we needed to do that, but it is a control we put in place weekly, but to do it.

Or I'm sorry, we put in place monthly, but to do it weekly or more regularly was a debate that we had. So I know we're coming near the end here, so I just want to talk about what's next for us. Like I mentioned, we're now going to be able to leverage RPA and finance, leverage RPA and finance, and, and hopefully more tools, too.

It's expanding to machine learning chat. Whatever else we can use for these teams on, this will help kind of stand that up. We want to improve the efficiency of our quarterly review process. Even leverage bots to help complete some of those reviews, is something that we're looking at, which could be great, and prepare for our first audit. Again, we've set up our controls, but we haven't even had them looked at yet. So it's going to be a reaction to the first audit and ongoing audits to make sure that we have the right that are controls, are working. But now we have greater confidence in our RPE program.

Eventually, when we move to a federated model, if we can do that, or get more citizen development going, hopefully that will, that will be more comfortable and easy now that we, now, that we have this in place.

So, that is the end, I think we're at time for questions, So I will turn it back over to Josey.

Fantastic, Marco. Fantastic. What a great presentation going. You know, over the governance steps, examples, and the other real applications, a lot of tradeoffs and decision making, that the that you had to make really, really appreciated the coverage and that that's that, that you have gone into. We have lots of questions, So, I'm going to start with a few here, as menu from the audience as possible. Paul, ask right away, when you're in the beginning of the presentation. He was interested, perhaps, on the comment you made about quality gains from the RPE program and he was curious when you were referring to those quality gains. Do you mean the quality of life improvements for Morningstar staff, the quality of work? What are you talking about there when you said that there were these quality gains related to RPA?

Yeah, sure, and that's a great question. So, for example, some of the things that we've automated, you know, we actually have a section that we'd like all teams to talk about, mistakes that they've had in the past.

So, for example, where we're translating a lot of PDF information, because long story short, we haven't been able to get raw data from one of our customers. So they send us a big export of PDFs, that we have to help transfer a lot of the data into a different format. And while the manual effort was very time consuming for the employees, and getting rid of that was a huge gain. And that was kind of a big focus. They also made a lot of mistakes. And that client is now seeing that the bot doesn't make those mistakes. You know, there's a lot of fat fingering that goes on. Sometimes, a few PDFs were missed.

So there's just a lot of room for error, especially when you expanded across thousands and thousands of PDFs, so that client, actually, while we had the internal gains, and the team was so happy to not have to staff someone to do that manual effort. They now no longer see those errors. And that's, that's something that you can really try and tease out of Teams with just about any process. So when we give internal report outs. And when we talk to, when we tell our story to help market RPA, we often talk about those kind of consistency wins. And similarly, we're process owners have had challenges and have
So it's all, you know, we try to always focus on the client and customer experience and how we're helping them, but internally, removing those hours from an employee's workflow, that's a question we always like to ask them to. How has that helped you? What are you doing with that time, now? How is it making you better? So yes, I do think it's a little bit of both, from the client perspective, Quality gains, and then also, how is your team more efficient now that you're adopting RPA? And that's a tough question to answer. And it can really get a team to think.

and even try and do more RPA wants to answer it for sure, for sure. Another question here from Jeff. He was insistent on the, you discussed this already, but a little bit further on the RPA organization and infrastructure that you have, you talked about having a centralized model. Maybe if you can, spell out a little bit more in terms of resources, and, and then what that team may look like, and the, specifically, when you started the program. How did that structure is start, and how, is it, it has evolved? How has it evolved over time? Yep. Yep, yep. For sure. So, so, we initially partnered with our vendor, had to get a lot of information, they helped us partner with our IT team to get all the infrastructure of RPA setup. We were empowered as a Quality Internal Quality Team to co-ordinate all of that. We do have some technology Experience in our Shenzhen China office.

It's actually a team that we've had historically prior to 2018, focused on building metrics and dashboards. We actually had an internal business intelligence tool that they would build, that we have quality and audit team members. You know, data is a huge part of our business.

So our team actually has quite a few I would say mid-level technology members right? Folks that aren't, you know, called core developers, but have a lot of good familiarity and exposure to code in the past. So they helped build dashboards, and we repurposed them are about 4 or 5, Anil, 4 or 5 of those developers in Shenzhen that we initially repurposed and gave them studio licenses from UI path. And they were the ones that started off the development, and then we slowly reached out to teams to connect them with that group, and kind of monitor the process. And it only took us a few months to then spin up a jira database, and build a framework for the intake process, and start to market it across Morningstar. And so then after that, we repurposed more developers, but we also started hiring, and we expanded to our Mumbai office.

So that's something that's pretty common across our businesses, that we're trying to build multiple centers of excellence for a variety of things, but but also for RPA development. So hiring developers in Mumbai really kind of helped expand us to the bigger group and give us more connection to the teams. The business teams that are operating out of Mumbai because nothing can be developer to process owner interaction. We decided to centralize a lot for cost effectiveness. You know, and there's a reason why we don't have developers in Chicago, because, you know, we don't necessarily see the value of those full-time, dedicated resources in the US.

salary base, but, but, know, there's a lot of value in having the business expertise in Chicago, our quality team, connecting with those developers. And as we're learning, it's becoming a much smaller world. So, really, the time zone variations aren't as big a challenge as before. So, I hope I answered the question I might add. Yeah.

That's great insight. There was a question from surely early on, and I think you saw this, and I'm gonna, I'm gonna build on that question. I know you have RFPs in production today, you answer that just give us a flavor. of how many what types you may have.

Yeah, sure. So, again, folks over 450 have gone live. We have a variety of Excel automation processes. You know, we're a huge Excel shop, so there's a lot of Excel automation, so we learned a lot about managing the macros about dealing with, you know, a lot of stability changes helping build awareness when Excel files are changing their locations, or changing or whatnot.

I think in my presentation, I highlighted that our investment management team is actually at the top Because they manage so much different business with our client accounts, and they have a ton of also besides Excel, automation, a lot of web based, kind of, even in some cases, some web based entry that they do. So, data entry is a big one, a lot of QA processes. I'll talk specifically within finance because you might've noticed that we have been able to go live with a few finance processes already, even though we're waiting on socks for some of the big ones. But a good example is, when we were integrating one of our companies that we acquired years ago, with our instance of Salesforce so that we can manage our financials. We had a lot of problems. We have a very customized Salesforce instance at morningstar and they had a very clean instance. So fitting them into our model was very difficult. So the team was really at a loss, and they kinda needed to just copy, paste some information from the new companies instance into morningstar's rough one, and what a better solution than RPA.

So, we actually have a daily export of master data, client data, some contract information out of one Salesforce instance. And just import it into our instance, to avoid that integration that avoided a nine month integration project, just by doing some copy, paste that, before RPA, you know, and even building an API. Like, who knows what we would have had to do, we probably would still be doing that manually. So, those are just a few flavors. You know, a lot of, Salesforce automation, a lot of Outlook SharePoint Excel files, but yeah, we've in 2.5 years, we've been able to save over 60,000 hours. So we've been doing a lot of work.

That's outstanding. Outstanding Margaret. Now we're almost at the top of the, of our session here. So I wanna, I wanna answer a quick one here. Real quick final question. That came from Santana and I want to build on that as well because she asks about how you're marrying RPA in Lean six Sigma and the and on that I also want you to quickly describe how you how you are not only marrying with Lean six Sigma, but also how you're prioritizing all this potential opportunities for RPA.

So if you can discuss that.

Yeah. Yeah, absolutely. So, I guess I will answer the law and symbolic, so marrying continuous improvement. We have an internal quality team that has been, like I said, training and coaching, on Lean six Sigma for years. So, we have a number of teams that have already mapped out their processes already, identified their waste, but we continue to do that, right.

There's, there's plenty of opportunity to continue to identify, what, what would be a customer facing goal, how we can meet those customer facing goals, and where we have waste. And a lot of times, it's repetitive processes, lack of technology, lack of efficiencies. So, I view RPA as a great solution to a continuous improvement teams efforts, right. Like, we often talk about, or you don't want to jump to solutions when you're doing Lean six Sigma. That's kind of a big behavioral aspect of it. But in some cases, once you hit that improve phase of demand, RPA is going to have to be a part of the conversation. And it's actually been a great segue for us to promote both Lean, but then also be able to promote RPA, can you leverage a chatbot. And just helping things, teams, think a little bit differently. And even kinda trying to turn those into more transformational projects.

As far as managing priorities across a, a variety of teams, not easy. You know, we have pipeline, that ebbs and flows. So, sometimes we're chasing projects and trying to get more work for our developers, but, you know, majority of time, we have probably more projects that we can do. We've actually moved to an Agile model, also something that Tony talked about yesterday, which was was very enlightening.

We're kind of shifting to more two week sprints, morningstar, and even my team has been adopting agile. And becoming an agile shop for years as well. So, a lot of our software development teams have already shifted to the scrum model and are kinda organized in small teams and sprints. And while we don't partner our developers with process owners like a traditional Scrum model, We are operating in sprints to be more predictive. Understand how many projects we can review in a given two weeks, how many we can develop in a given two weeks, so that we can have more predictability as projects come in. So it could be anywhere from, we can start this one right away to, it's going to be, you know, a few months before we can get to this one, and then kinda managing the predictability from there. So it's good, we're more predictable. But then we also kinda try to try to make sure that we balance across the teams.

We help, we want teams to prioritize themselves. So, think about the ones that are going to have the most impact, or the most frequent, the most stable. The touch, the least amount of applications, have the least amount of exceptions. I'm so that they can kind of prioritize, too, So that they know that they're giving us their top ones first. But then, also, in some cases, will partner a specific developer with the team to if one team really is working with us closely. and feels like they need, better, partnership will actually dedicated developer to them. It's a lot of budgeting issues when we have this centralized model, even with the licenses, so we have to work through some of that. But, But, yeah, it's really what, what does the business need? You know, we try to prioritize from a business standpoint. But we also tried to be fair across teams. And, if necessary, will hire more developers. So it's keeping an eye on kinda the whole gambit.

Yeah.

Mark, thank you so much for sharing your insights and expertise. You have so much passion and knowledge about the subject. Really great to have a leader like you, sharing this experience with us. We're very privileged to have you, thank you for that. My pleasure, thank you so much. Appreciate it, forward to the rest of the conference.

Thank you. Ladies and gentlemen, we're going to be closing the session, please provide your feedback, as you close the session, on the popup box that, that will come up. Also, remember that, June 23rd, for June 25th I, BPM, the IBM event, will be on another set of Incredible speakers. Joining that, you can learn more at I BPM, live, dot, all. line. You, see on the chat that we transmitted that link to you as well, and we're looking forward to seeing you at the top of the hour. Another great presentation with the Senior vice-president of product from UI Path, Brendan, Not, is going to share with us insights on the mission for a robot, for every person, you do not want to miss this session.

Especially if you really want to know what, what, what, not only the current state of RPA, or but also the directions that we're moving towards. So, thank you very much, and I'll see you at the top of the hour.