9 Steps to RPA Success

Hello and welcome to another episode of the Process and Automation Podcast. From working with our customers over the last couple of years on robotic process automation projects, Arno and I have identified 9 steps which lead to RPA success. In today's episode, we will share our learnings on getting started with robotic process automation. So yeah, hello everyone and welcome to, to the episode of the So, yeah, Arno and I am here to go through the 9 steps of RPA success. And yeah, we like to go through them one by one, and at the end of the whole episode, you have a good understanding what is important. And yeah, Arno, so the first one I have here on the list is define your objectives. I think this is a good, good, important one to start with.

Yes, that's right, Sascha. I think if you look at industrial automation in the past and the repetitive nature of what industrial automation did and still doing today, we can also apply those techniques to repetitive workflows inside a business, and we can enhance those workflows by using smarter automation, by deploying robotic process automation, which is really just software bots that actions tasks very quickly and in a repetitive fashion. Now, planning is essential before we start our RPA initiative, and these 9 steps we're going to present today, we, we need to define clear-cut goals and stages for our RPA initiative. And, you know, we need to chart a course, we need to have specific milestones. And hopefully by following these easy-to-follow 9 steps today, that would lead to your RPA success or starting your RPA journey. And also you need to understand where, where RPA fits into your digital transformation goals and the digital transformation journey, because of course that's just one part of it. So Sascha, as you said, define your objectives.

Yeah, thank you, Arno. Yeah, with every project, as you mentioned earlier, it's very important to really know where the journey really goes to. It is very important to define your objectives and your outcomes for the project and for as well for the whole business. So when you hear about these interesting technologies you have to think about what do you want to get out of it. So I think that's the key bit. And similar way how you define what you want to get out of a new house you want to build. So it's very similar. You have to think about starting with new technologies like RPA, robotic process automation. So think about what you can achieve and want to achieve with it, and what productivity measures you have already in place, and how can you maybe exceed them, what is important to you, and as well along the line, how can you actually improve your staff experience, your customer experience as an overall goal potentially. So yeah, defining objectives like with anything in life really, and in business, is the first point.

Then I would say the second point in the 9-step process, step 2, is finding opportunities. So you've set your definitive objectives, and again, let's say you are looking to introduce scalability in your business. That's a tangible objective. Once you've got those objectives in mind, you need to go out and find these objectives, or these opportunities rather, using that objection or that lens of objectivity. And things to look out for is processes that's got very high volumes of data. So you could easily look at that and say, well, we've got these finance processes, there's a clear opportunity here because we're seeing a lot of churning of data, that might be a good opportunity for automation. Also, what we're looking out for is processes that's got a recurring frequency, things that happens a lot repetitively. Like I said earlier, in the industrial automation, it's stuff that repeats predictably. So that's the same for these processes that recurs frequently. It's the things you need to look out for these repetitive processes. And then also processes that require a high degree of accuracy where human error is out of the question. You know, again, with financial data, it's very important that those, those types of processes produce very high degrees of accuracy.

Yeah, I think all these These processes we then have identified, we now need to check with experts in the business and with experts in the RPA and process field, what is the potential of these processes we have identified. So if we come up with a list like Arno, you just mentioned, we then should look at each of these processes in detail and, and really see, are they actually feasible to implement? Is it complicated? Is it complex? Are they actually more important than others? And so yeah, this, this requires a lot of knowledge. You need to get around the table and to discuss and bring company groups in, members of the team to discuss potential. And yeah, and then you have a, a better understanding of what is really the process or what these are, these processes to, to implement.

Yeah, I think with the opportunity validation, you know, the key there is to find the best choices. For, for the, the processes or the opportunities that you have identified. I think a key driver is also to look at the business value versus the feasibility of implementation. It might have a huge business value, but if it's impossible or very complicated to implement, and that sort of fails your opportunity validation. And again, remember, this is to start RPA. As you progress and mature your RPA initiative, you might go after things that is quite hard to implement because you've already implemented all of this low-hanging fruit. You've picked all of that. So you see you're kind of progressing up into automating some of the trickier things. And Sasha, like you said, you need to bring together your RPA experts and your process experts to, to, to really review these opportunities and also the details of the implementation, because that kind of brings you back to the feasibility. And in my view, this, this is your opportunity then to define some, some success criteria in a process. You know, we don't want any errors in this process. We want to save X amount of hours per day, and we want to reduce operating cost. And I think once you've got that, you know, you're in a good position then to establish governance, to say, well, you know, we have got a clear objective, business objective. We have found these opportunities, we've validated them. If we were to implement these, what type of governance do we need to put in place? And this is really where we bring IT and the business together. Because if, if RPA is part of your IT strategy, it's really important to, to align it with, with the broader business and their objectives and initiatives that they want to, you know, do with inside the business. So it's really key for, from a governance perspective, to incorporate IT because ultimately You know, they're going to be the people that provide you with RPA training, and they're going to grant you access to systems that RPA robots need to source data from. So it's key to ensure that they're on board with the initiative. Of course, if your business is really large, RPA can be really strategic, so it's recommended that the RPA has got oversight of your project management office, for example, so that they know what is in the pipeline for RPA.

Yeah, that's a dream, IT and the business aligning very well enough. But yeah, one thing I thought as well, so having this shadow IT creeping up is quite important. So we don't want, just because someone wants to avoid IT, but we don't want to have system we suddenly need to support we didn't know about. So there's This is the horror scenario, especially when those of these RPA experiments became quite important for the department. So yeah, it's very, very important to get that right. So yeah, that brings us to develop a plan. So since RPA will have an impact on the organization, especially if it's a large organization, It makes sense to plan an implementation very, very carefully. So you need to anticipate and plan for all areas RPA might have an impact to. So it might be that it includes employees suddenly have different job responsibilities. Because RPA is taking over some of that work they're currently doing. So it might need a bit of retraining so other employees can then do some other valuable stuff in the business. So a part of the technical side, so you need to have a good plan in your organization to roll out and successfully roll out long term. And yeah, I think that all needs to be put in typical document structures, formal documents, so that everyone can review it and discuss it, and there won't be any surprises to whole departments or divisions of a larger organization, or even in the small companies the same. So yeah, so that's very crucial to plan that with everyone who is involved. It's a very important part to make RPA a success.

And I think the planning is, it's, it's really planning for change to roles and responsibilities of people. So you might have a person that has got pre-RPA specific roles and responsibility, post-RPA that's going to change, they might be redeployed to something else. So, so you need to evaluate those impacts to, to the employees and their roles and responsibilities And then also from a business perspective, plan how you're going to address that and the expected changes to the roles. And you need to understand the impacts of these changes to people's roles and responsibilities to their day job. And that's really important. And, you know, a solid plan is really key to the success because operationally people are set in their ways. And the way of working pre-RPA is going to be different to the way of working post-RPA. So it's really important to have a very clear plan and to articulate in that plan, you know, how you're going to deal with those specific changes of redeployment of staff. And I think, you know, once you've covered these 5 steps, again, just to reiterate, you know, we've defined our objectives of RPA. We found good opportunities. We have now validated the opportunities. We've brought IT into the picture so that, you know, they're part of those conversations or for governance. And we've got a good change plan with inside the business to how the roles and responsibilities will evolve. And the next step would really be to spin up a trial or proof of concept. So let's pick one of the actual opportunities that you found. And, you know, let's build out a proof of concept that shows, you know, the feasibility of your plan. And you do this before you do large-scale rollout, because that's important. You evaluate your proof of concept and all of the sort of elements of the previous steps Our recommendation is you do that really in a controlled environment, a test environment where operational or business operations are unaffected. Business can continue as usual. We've got a pilot or proof of concept running side by side. The recommendation is that you do that for a period of time before your RPA system actually gets deployed, you know, into a production environment. And I think this is also a very key moment where you can look at your trial or your proof of concept, and you can look at, well, you know, has this actually met our success criteria? So for example, if your success criteria was to reduce operating costs or to improve customer experience, then you need to measure that. You know, is this actually doing what it was supposed to, to, to do? And you shouldn't be scared to, to, at this stage, to rework if, if you need to, or to change direction and try a different pilot. So I think that that's, that's quite key. And I think at this stage, for your first RPA project, Vendor selection will also come into play where you might look at, you know, all of your objectives, the types of projects you're going to do, IT governance, you know, your, your business change planning, the outcome of the trial. And you might decide, I, you know, feel like UiPath is a good, a good candidate here because it's got automation happening. I— you might think, well, we want to do Blue Prism because of the ease of deployment, or Automation Anywhere, or KNIGHT, or any, any of the, the sort of the vendors out there that, that really compatible, you know, with you meeting your objectives. And, you know, I think Sasha, you will agree that, that, that's part of the remit of what we do is, is to try and shape that for companies and try and make that decision-making for vendor selection really easy, right?

Absolutely. Yeah, I have, I have one question which came, came up just now. How, how do you think, or what do you think is the best time frame to run a trial? For how long should we keep it running for?

Yeah, it is a good question. We've just came out of a successful trial that we ran for a period of 3 months. And, and when I say 3 months, it was 3 months from, you know, first setting objectives to actually pilot deployment. So the development was really just at the tail end of that. And we think that tends to be for a medium to large size organization, perhaps not enterprise, a sort of a good period of time to, you know, to address or to go through all of these steps.

Otherwise, people start to lose interest again, isn't it? So that's what we see a lot. Yeah, so if it's taking too long, people forget about it even.

Yes, that's right. But I think, you know, each organization is different. You know, some people might decide to, to run multiple pilots simultaneously, which is not unheard of. I think It is just a function of the appetite of management to introduce automation within their business and then buy-in from end users as to, you know, what the type— what is the type of impacts they'll see to their roles and responsibility. I think some employees are on board with it because in this particular trial that we've deployed, saves one person 3 hours a day, which is quite significant.

It is, yeah.

And it's 3 hours a day of mundane work. I'm not talking about 3 hours a day of work they enjoy. It's really something they don't really like. And so there's a high degree of end-user satisfaction there because we're giving them time back. And, you know, this, this, there tends to be, to come back to your question, how long do you need to run the trial? Well, I think that you would, you would soon find out if the trial is successful or not by, by looking at the feedback from, from these people that you are making impacts, um, to, you know, to their, their day-to-day roles and response roles and responsibility with inside the business, right? Great. Thank you.

So that brings us to deploy a solution as our next step. So once the trial has been successful and all the experiments has been successful, even if it has been a series of trials, yeah, so the next step can actually start. This is usually where people get really excited because they can envisage the great results from the trial. Already in production. And yeah, it is absolutely fantastic if you can save 3 hours, for example, per day. And if you see this happening already in production, then yeah, everyone gets really, really excited. So, but there's still something to do to deploy a solution. We shouldn't forget about the typical steps we usually run through when we deploy a solution. It's— so still we need to do technical documents and business documents, and so all these things to really build and code and into a full solution. So that all needs to take place even in our RPA world. And yeah, so we can then think about those steps in detail and put this all into action, give full speed on the development, put this all into production systems, get our people trained, very important, so that no one is surprised when things happen on go-live date. So yeah, there's plenty of stuff to do. But yeah, similar like we have done before, when we plan properly, this, this whole transition will, will be a smooth one, and then we can get excited about the results.

Yeah, and I think it's just a question of rinse and repeat, because once you've deployed your solution, the pilot solution, when it's successful, there will be adoption. Because if you're starting to save people's time, it's highly unlikely that they're going to want you to turn that solution off, that time-saving solution. So there will be a degree of taking your pilot and productionizing it and strengthening it and perhaps, you know, looking at enhancing it, and really just tracking its progress. And, you know, looking again at the success metrics that you've defined in your planning phase, you know, your KPIs, for example, that you want the solution to adhere to, you know, to judge the success. And, you know, again, examples of success metrics is, you know, did it provide us that higher accuracy? Did it save us the time it was supposed to save us? You know, did it improve productivity? Are we seeing more things happening now with inside the department that this was deployed to? you know, did it provide that better end-user or customer experience that we were after? So these are all kind of success metrics that, you know, when you deploy the solution that you can measure. And I think you should always ask yourself, you know, if you didn't reach these goals, you know, you ask yourself, why didn't we reach the goal? And, you know, like I said in a previous discussion, Different people might have different views on what success criteria is. Management success criteria might be, well, this need to have a cost saving of a certain amount. It might not reach that, but if you speak to end users, they're like, this is great, this saves me 2 hours a day or even 1 hour a day. For me, this is a big success. So it can be sometimes a bit subjective if you look at success criteria. But failure, you know, is something that you need to be able to deal with and learn from your mistakes, learn, you know, lessons learned and all of that. That is quite kind of cliché-ish, but it is still true in this sort of, in these sort of projects. And you need to challenge yourself on these sort of things. And, you know, I guess that kind of brings us into the next step, the sort of improvements.

Yeah, indeed. So yeah, RPA is definitely a journey. It never, never finishes with this one, with this one implementation. You're always reflecting on how it's working, and if we, if you see in some areas of the business new opportunities come up, we obviously take take RPA into consideration again and then see what that might bring in that area. So we will always continue to look out for opportunities and the existing processes we always continue to improve. So this is very important that we keep that going. It's very, very normal in business process management in general to always analyze and to improve and then again get into action. And this also applies here a lot. So it is very iterative. And yeah, so the constant feedback from staff and customers is also very important, which leads us then to new projects. And then the whole circle, then we start with step 1 again, and hopefully we can produce more and more those successful implementations.

Yes, I guess in summary, so if we look at those 9 steps again just briefly before we wrap this up and perhaps move forward to providing some examples of a typical project. So again, the first step is to define those objectives. Let's just say cost savings is a good example. The second step you know, find those opportunities, look at those highly repetitive processes, look at those processes recurring frequently, and document those opportunities, and then validate it, you know, do analysis on it, feasibility analysis, and bring those RPA experts and the business experts together so that they can discuss the details of the implementation with the view to choose a successful her first pilot. Um, the next step, the fourth step, is look at your IT governance. Bring in the people from IT, make sure they're on board, because they're the people that ultimately needs to support this, provide training. Um, business change planning, step number 5, very important. You're going to bring something into the business that potentially pre-RPA will change the roles and responsibilities of people, of staff. You need to plan for that, have a positive sort of mindset to that. You're going to give people time back, you can give them time back to do better things in the business, and then run your trial, you know, run that trial, make sure it's in a controlled test environment, ensure that You run that for a period of time, validate the success before you push that into production, which is the 7th step. Deploy that now and then really rinse and repeat what you've done in the preceding steps. Choose another opportunity, you know, push that through. You might not decide to trial it because you've got enough experience now to know what to look out for to push that into production. And then I guess the last two steps is track the process of these RPA projects. Are they actually realizing your initial objectives of higher accuracy, better user experience, scalability? And then the last step is really just that closing that loop to make further improvements, right? Like we said earlier, this thing's not on autopilot. It's something that you might look at and say, you know, we save 3 hours a day, how can we save 4 hours a day? You know, how can we, how can we make that better? And so it's a constant sort of cycle of improvement, right?

Yeah, absolutely. I think one, one thing I usually like to mention when it comes to RPAs also, starting small. I think that's important. So the opportunities are great. There are lots of opportunities out there, but just taking the biggest challenge straight away sometimes leads to failure. So very often we advise to start quite small. So you have this bigger picture in mind, that's absolutely fine. So you have the big goals, but especially in the beginning when you embark on that journey, then take, take one department at a time, less complex maybe in the beginning, and then do these iterations, do these 9 steps, and then, yeah, then take the next big project, 2 departments, 2 divisions lots of integrations, lots of stakeholders to manage, um, yeah, and then, yeah, go from there.