Automation Journey of Bupa Global

Abhiram Mahajani: Hello and welcome to the Infosys applied AI podcast. In this show, we host our clients, partners, and Infosys applied AI professionals who are doing some remarkable work in this exciting space of AI and cognitive automation. We explore what does it take to build successful scaled AI journeys and how the industry is evolving to make this a reality. Welcome onboard.

Abhiram Mahajani: In the previous episode, we talked a bit about MLOps which was a rather new concept in the industry. And today we are going to talk about something which is well established. So we are going to talk about process automation. But while it is well established, it still needs a lot of things to be in place for the initiative to go right. And that's exactly why it's very relevant, even today to sort of have the right kind of experience and exposure to key factors, for something like this to reap the right results. So, to discuss this specifically, I am having with me today Mr. Steve Williams from Bupa Global. In fact, I'll let Steve introduce himself, but we are here to talk about the automation journey at Bupa. So Steve, over to you first of all, thank you for joining and over to you for a quick introduction.

Steve Williams Thanks, Abhiram. Yeah, hello, everyone. I'm Steve Williams. I look after IT Strategy and Architecture for Bupa Global which is a part of Bupa. Bupa is a 12 billion pounds business, employing about 85,000 people around the globe. And it's split broadly into three geographic what we call market units. We put a global sitting within the market unit that is based out of the UK. And the UK market unit includes the UK businesses of medical insurance clinics, dentists, age care and the internationally renowned Cromwell hospital, as well as our Indian insurance business called Niva Bupa. Bupa Global, our main business is selling international private medical insurance, which provides top class health care across the globe.

Abhiram Mahajani: Thank you. Thank you for that wide introduction, Steve. And clearly I mean, when we say insurance. Given that I don't come from that domain myself, it's fascinating to know that there are so many angles and aspects to it. So great to know that. Now specifically talking about automation, I think we know for a fact that Bupa has been sort of a pioneer at such an initiative. And we know that, you've been running this for a while, I would like to sort of go to the very beginning of this journey. And if you could let us know how it started. What was the initial teams involved? And you know how it all began at Bupa?

Steve WilliamsSure, yeah, happy to. Part of my role is very much about driving innovation. Robotics has always been something that has been talked about for a little while. And within the market unit, there had been robotics being run for probably about 18 months when I started to talk with my colleagues in the market unit. And so we were quite lucky because the UK had set up this, what they call an RPA franchise, a robotic process automation franchise, and we were able to use their infrastructure to get going. So there was a lot of, you know, the stuff that you would normally have to worry about in terms of getting software installed and all the rest of it that we didn't need to worry about, we could just kind of get on with it. So we worked with a sort of third party to take a particular process and ran a proof of concept on it. It worked pretty well. And it was successful. And I think so basically proved the business case for us. And we were therefore able to go on with it from there. I guess the other bit that's probably worth mentioning within that RPA franchise model, is that as a consistent governance model that ensures that, you know, the process that you want to automate is a bit appropriate to do so, it's got the right information security and other compliance issues covered off, and just a nice consistent way of being able to deliver that sort of change into the business. We've now got six processes in production, a couple more close to coming into production. And we've got a reasonable pipeline beyond that. I won't go into detail about the processes, but it's interesting for me how they sort of break down into two or three different categories. The first category is probably the one that most people would think of, I've got this kind of fairly mundane, almost boring process that no one really wants to do, because there's nothing very interesting about it. It's just I've got to pull some data from this system to that system or whatever it might be. And I think that's what most people would see as a classic RPA kind of process. So we have some of those. But we have two others that are sort of popped up. One is, I would call it a sort of, like a helper process, in that it's not one that runs very often. So this is in our systems business. So a part of our offering, is evacuation and repatriation services, where if our members are in trouble, or you know, they've got something seriously wrong with them, we will get them first to the most important place for treatment, and then get them home again, that service is carried out with a sister company of ours called GeoBlue in the US. And we are in the process of integrating systems. But at the moment, we haven't got the full integration in place. And so what we're doing is we're using the robot to effectively transfer quite a lot of data from our system to their system when it's needed. Effectively by that I mean their system to Salesforce system, they've written a, just a very simple portal page, I say, simple is a lot of data, lots of fields, but the robot just picks up that data and puts it in there. Of course, the nature of the business means that the call for help can come at any time, day or night. And so the robot is there running 24/7, I would just say that it's not critical to the system in that if the robot doesn't run, then there's obviously a manual process that kicks in. But it's a very useful part of that process. And I think that, you know, this is where RPA can be, can be useful for filling those gaps about integrations between systems that aren't really there, and allowing that work to happen. And maybe further on down, you can, you can put that integration into place. And the third, the third example is we're going through a very big migration process at the moment, we have two IPMI systems that manage our members and our claims, and we're closing those down. And so, we're migrating the data from one system to the other, there is an automated load process, which happens every month when the members renew, but it doesn't cover every case, there are some unusual cases. And what we've done there again, rather than write a load of code to handle those unusual cases, which will obviously throw away in a year's time, but we've basically taken a robot to make that process where so much quicker to get the robot to learn what to do. And then when we finish, we can just close it down. And there we go. So yeah, it's been it's been a very interesting journey. And it's quite interesting when you asked that question, it takes me right back to the beginning. And it was a, you know, baby steps at that stage.

Abhiram Mahajani Indeed, indeed, and you know, what's interesting for me to listen to this is the variety of use cases that you mentioned, because typically, in the industry, you will find automation being classically applied to, like you said, the mundane tasks. And it usually starts with, you know, finance and accounting or some of these standard areas. But the fact that you've been able to identify some of these very specific scenarios and sort of domain specific scenarios. That's, that's great. And I'll come to a specific question around that a little later. If I want to know, a little more on, you know, I'm sure this has, this has not been an all-smooth journey. So, there would have been a few hiccups? Would you like to share some specifics on those wines, with some of our listeners for their experiences?

Steve Williams Sure, I guess the, the sort of first challenge in many ways is, is to make sure that, you know, we don't get overrun by the hype. So a lot of my business colleagues will, you know, they'll have a chat with somebody who's a robots of the future, and all the rest of it, and they all sort of come in and think that, and they'll talk to the vendors, and obviously, the vendors will tell them a good story. And they'll often think they've got a silver bullet. And that's obviously not the case. You know, sometimes they feel that they won't have to worry about things anymore. It'll just happen. But of course, they still need to be responsible. And they still need, they do need to help us particularly during the development and testify ease. Because some, particularly some of the processes can be very difficult to get good test data for. And we actually need the business people to generate that data. So I think we have had some challenges where it's not been realized, you know, and I think some of that is, you know, collectively our responsibility, because we were relatively new to it. But what we have learned is that, you know, yeah, we do have to work together and make sure that we have the components that we need in order to make the thing successful. Another thing that we kind of learned was that I mean, there's a couple of ways of kind of running the robots. One is to effectively say to the business team, data robot, you run it, or another way as a sort of more centralized model, where, if for want of a better phrase, you kind of got expert robot users who can do that. And we've transitioned from the former to the latter. I think we started with the view that because the business guys know the process, when they hit a problem, they can deal with it. But actually, what really happens is you train the robot to do the process, so the robot doesn't need any help with the process, it knows what to do. And it knows the situation, if it doesn't know, it'll raise an exception, and it will get passed over to the business team. And what was happening is that the problems that you do here are more kind of infrastructure type problems, you know, there's been a, I noticed a service, there's been some patching on a server and when it when it comes up, it doesn't start properly, or, you know, whatever it might be. And so I think we have moved to that model of a more centralized control room, if you want to use that phrase. And we found that that works, that works much better. So that was it, that was a good learning, we did have a, I would say, the other thing is probably more to do with how, again, how we first started, we kind of probably didn't have as an experienced team as we as we should have done. And so I think like, like anything, it's always good to have good experts involved, we've got that now. And the difference is, is huge. You know, from my perspective, personally, I have nothing to worry about, the guys are great, and they get on with it. Whereas previously, maybe I was getting a little bit too involved in what was happening. And I guess two other things that are worth just bearing in mind is changes in the systems that the robots working with, can often trip you up, might be as simple as the movement of a field on a screen or the jury to an upgrade. And then the robot suddenly doesn't know what to do. What's been interesting there is we again, we were sort of a bit worried about, okay, every time there's an upgrade, we need to do a lot of testing with the new version of software. But we thought we find that in reality, probably 90-95% of the time, there's no impact. And so all of that testing is a bit of a waste of time. So the approach we're actually taking now is not to do the testing and in effect, to let it fall over in production, but to be ready and fix it, because again, we find that usually it's a fairly minor change, maybe a position or a slightly different order of a screen or something. And they can be fixed within a day or two. So I think overall, that's a more effective way to do that. And obviously, I think that's, that's the sort of thing that will depend a little bit on your individual situation, you know, our systems are relatively old, so they don't change very much from that point of view, if you've got newer systems that change more often, you might want to take a different approach. And the last thing I was just going to touch on, not really a problem. But we were originally kind of running the robots manually. So somebody would have to log on and kick the robot off. But we've now use an automated log on feature that comes with the RPA software. And we're able to effectively control when the robots run and what they do if they fall over and all of that, all of that kind of stuff. And that obviously means that we can be much more effective with the robots, because now we can really look at 24/7 running. And that's kind of where we're going to probably, you know, be looking in the future to maximize the value that we get out of the licenses.

Abhiram Mahajani Oh, thank you. I think clearly, it shows that you've had certain course corrections as you've been on this journey. So the fact that you started off on a particular model, very interesting that you mentioned the support model as well, because I've seen that that has been a sort of topic of debate, or I've seen both the models, having their merits demerits, in terms of whether to have the support with the operations team, or whether to have it centrally with the IT or say alongside IT. And the fact that you have been able to naturally course correct, learn through experience, that shows that that's exactly how the journey is going to be for some customers who are trying to adopt it newly, that it's not going to be, you know, a silver bullet, as you said on day one, but there will have to be these course corrections. So we'll be happy to see that.

I'll go to the next question, which is, which kind of links to your previous answer. So you've been on on this journey now you've done a number of automations, there are a few in the pipeline, I would say this is this is a fairly mature initiative at this point. And if I were to say, you know, define the levels of maturity, it's typically defined by the kind of adoption that you see and the kind of acceptance that you see from business. Now you already have a few use cases in the pipeline. And some of the ones that you mentioned earlier, were very unique. So where did these ideas come from? These came from the automation team, or these were given by business? How did this happen? And how do you see that happening in the future? Over the next say, year or so?

Oh, thank you. I think clearly, it shows that you've had certain course corrections as you've been on this journey. So the fact that you started off on a particular model, very interesting that you mentioned the support model as well, because I've seen that that has been a sort of topic of debate, or I've seen both the models, having their merits demerits, in terms of whether to have the support with the operations team, or whether to have it centrally with the IT or say alongside IT. And the fact that you have been able to naturally course correct, learn through experience, that shows that that's exactly how the journey is going to be for some customers who are trying to adopt it newly, that it's not going to be, you know, a silver bullet, as you said on day one, but there will have to be these course corrections. So we'll be happy to see that.

Abhiram Mahajani I'll go to the next question, which is, which kind of links to your previous answer. So you've been on on this journey now you've done a number of automations, there are a few in the pipeline, I would say this is this is a fairly mature initiative at this point. And if I were to say, you know, define the levels of maturity, it's typically defined by the kind of adoption that you see and the kind of acceptance that you see from business. Now you already have a few use cases in the pipeline. And some of the ones that you mentioned earlier, were very unique. So where did these ideas come from? These came from the automation team, or these were given by business? How did this happen? And how do you see that happening in the future? Over the next say, year or so?

Steve Williams Yeah. It's a really good question. I mean, obviously, when it started, we really had to go from our experience. And you know, I've been in the Bupa for 15 years. So I know the business quite well. I know some of the challenges they've got. And so we were able to identify probably a couple of different processes that we thought were good candidates. And as I say, we've managed to we've got one up and running quite well. And then of course, it's really communication. I mean, it's really about saying to people, we have this tool. It's neither the magic bullet, nor is it, you know, the other extreme taking forever to build, it's quite quick to build. And what we've really done is identified the sort of characteristics of a, of a process that make it a good candidate for our PA. And you know, and those are the sorts of things I'll be, you know, hot, highly repetitive, low number of exceptions, obviously impacts OPEX, that's always a good one, because people are always interested in saving a bit of money. And also, you know, is it similar to other processes, because you build a library of elements to your processing. So, once you've written, say, a log on process to a particular system, if you want to log on to that system with a different process, that piece of code is already there, you haven't got to you haven't got to rewrite it. And then I think, you know, I like to think you get to a point where your success starts to sell itself. You know, we presented a couple of times at our leadership calls, and that's really generated a lot of interest, you know, and now we kind of getting people popping up all the time saying, Oh, I've got this potential opportunity for roboticized process. And then we kind of talked them through, will typically get someone just to give us a very quick walk through the process. And now I think we're getting to the stage, particularly because we involve the the actual RPA developers in those meetings. Sure, you know, we very quickly can say, that's a good candidate, or isn't, because the guys will just ask, you know, probably two or three questions about what happens in that scenario, what happens when this goes wrong? And you know, all of a sudden, you're saying, Oh, actually, there are too many variations in this, to really make it a good candidate. Or, actually, this is a good candidate, because the variations are right. And then sometimes what we do is, we might shrink the scope of the process or even broaden it depending on depending on that conversation. So I think that, you know, it's that open sort of conversation with the business about what's possible, and what sensible. And that really helps us to identify what the processes are that we that we should do.

Abhiram Mahajani And I think clearly, I mean, it's, again, reflective of the fact that you're sort of building this as an initiative, which is internally accepted, it's sort of openly discussed about and it's evolving by itself. So it's not something where there's a set framework, of course, there is a framework, but then it will evolve, and it will continue to iterate itself. So that's good to know. Now, again, linking to your previous answer, right, so you mentioned certain standards that you follow to identify candidates. And these are clearly standards for automation, pure play automation. I have seen in enterprises, the same automation initiative, starting to evolve into an AI initiative as well, or say elements of cognitive automation and AI coming into the same mix. Do you see that happening at Bupa? And where exactly are you on that journey?

Steve Williams Yeah, I mean, you know, but I don't think you can be in IT these days without talking about AI. So yes, I mean, in simple terms, yes, we're looking at AI. I think that, I mean, in my mind, I think there's a very clear distinction between RPA and AI, I see them as complementary technologies, rather than, you know, one overtaking the other. And I think one of the things that is important, is the kind of compliance side of things. So obviously, in our business, one of the things that we need to do is to work out whether we're covered, we cover someone for a particular treatment, and that's, you know, that could obviously be a very big decision for people at a personal level. And if we use AI to, to make those decisions as is, you know, the sort of thing that we're thinking about, we need to be able, we need to be crystal clear, in able to explain how we came to that decision. Otherwise, you know, you're going to be a very difficult position. And whereas RPA, of course, is really mimicking the process that a human does, I think it's really important to try and keep those two things separate. Otherwise, what will happen is you're slow down both sides of that equation. I think AI is important. I'll just give you a couple of examples. And so in Bupa Global, we've got a machine learning process going on, looking at our claims data, I guess we probably pay, getting towards three quarters of million claims a year from all over the world. And you know, this, what we're doing with this particular machine learning piece is looking for fraudulent behavior for now medical providers, which unfortunately, we do see, it is spotting some things which are allowing us to have some conversations and hopefully correct that behavior. But I would say that I do think it's a case of making sure you use the right or rather you go after the right problem. So one area that we've looked at quite extensively, is kind of automated extraction of data from electronic documents. So the obvious thing for us is we get an invoice for a medical provider, listing out the treatment that members had, we need to get that into our system so that we can work out, you know, what was what was required that of that invoice. The problem that we've got, is we pay claims in 220 countries around the world. So those claims come in all sorts of shapes and sizes, all that even within the same country, they're different states. And what we found is that, whilst you can get an AI to look at it, I mean, essentially, what you're saying to an AI is here is an invoice in a format you've never seen before, can you pull the data? And, frankly, they don't. They make they make an attempt. You might argue they're reasonable, but it doesn't get us to a point where it's a, it's a shift for the, for the business in terms of improving the process. Because if we don't get to a high enough competence level, someone's still gonna look at that piece of paper. And so that's a good example, I think, where we need to be careful not going chasing after the silver bullet. Now, in the UK, for example, it's a bit different, because there's much more consistency in the layout of the documents they get. And I think they've had a look, and there's some real opportunities for that. So yes, I mean, in answer your question, AI is very much on our agenda, but it is about making sure, again, that we don't, you know, don't swallow all the hype, and just make sure that we know what the problem is we're going after, and in particular, what is what is this? Where do we need to get to in the solution? You know, it doesn't need to be perfect. But it does need to, you know, obviously provide enough value to make it worthwhile.

Abhiram Mahajani Indeed, I think you really have in some great points and just summarize in this way that there is technology, of course, and the world is talking about AI. There are certain limitations to that technology again, right now as we are and those limitations are going to, I mean, they may get overcome, but they are there and we acknowledge those. And that's where it's very important to sort of work with those limitations and identify the right use cases. I think that's one of the key takeaways for me. The other thing you very interestingly mentioned of responsible AI and the explainability angle. And so in fact, I did my previous episode on the same show, we talked about ml ops, the same concept sort of extends into responsible AI. And I do have an upcoming episode on that. So maybe we'll end up discussing some of those aspects with you on that. Steve, I look forward to that as well. Thank you so much for your time, Steve. I think it's been a very engaging conversation. It's been great working alongside you over this over this while and I think today we've had some good takeaways from this session. To our listeners, feel free to drop us any questions that you may have on this and we'll be we'll be glad to engage further. Once again, Steve, thank you for your time. And I really look forward to be in touch with you, Steve, and maybe record, you know, a next episode sometime next year or so to see where you are further on this journey. Thank you so much.

Steve Williams Abhiram it's been a pleasure talking to you.

Abhiram Mahajani We hope you enjoyed this conversation. For more such talks, do subscribe to the Infosys applied AI podcast on any of your favorite podcast platforms. To know more about what we do in this space to visit infosys.com/appliedai. And if you happen to have any suggestions or if you feel like joining these conversations, do feel free to write to us at appliedai@infosys.com. Thank you for listening.