#4 Getting started with RPA: From idea to go-live

Hello and welcome to another episode of the Process and Automation Podcast with the Automation Guys, the best podcast of free, useful, and valuable knowledge about process and automation. Hello and welcome to another episode of the Process and Automation Podcast. In the last episode, we have shared our 9 steps to RPA success, and today we want to look again at the topic of Robotic Process Automation, and this time we look at a more practical example, something really relatable. Arno, what example did you bring with you today?

Hi Sascha, thank you. So today we want to touch on an example around time and expense management. As you know, within site companies, you might want to track time and expenses on a project level. Now, there's a lot of cloud-based solutions out there where staff can log in and log their expenses and their time against specific projects. And what we want to do is we want to export those transactions to be reviewed by a person, perhaps in finance or project manager, approve those, and then upload that into our finance system for, for payment. Now, when you look at this, this process, um, it's quite simple. We need to log on to an external system where we can perhaps download a report. Once the report is downloaded, we can export it to, for example, Excel. and then in a manual world, that Excel spreadsheet will probably be sent to somebody to review the transactions. And then once the transactions are reviewed and approved, um, that person would perhaps send that on to finance, where, um, somebody in finance will perhaps line by line look at each of the transactions and copy and paste the data within Sighted Finance system. So obviously what we want to achieve is inject some robotic process automation in here to really automate this, this process so that it could be something that's, that's a hands-off process where the robot can automatically log in, do that data download, do some automatic approvals on the data based on rules, and then once it's done, log on to the finance system and automatically key in this information into the finance system, you know, for the expense to perhaps be paid out, right?

Yeah. What would the robot do if something in this automatic download needs to be approved by a human, by a person?

So one strategy would be to— obviously, if there is a transaction that needs to be flagged to a user, Perhaps that could be, you know, written in a dashboard of some description. Perhaps you could use a low-code application form. You could write that transaction in there and simply provide perhaps a tick box for approver to tick to say, yeah, I'm happy with this. And at that point, the robot will take that transaction as approved.

Interesting.

And then import that into the finance system.

Oh, very good. So yeah, when I guess before we can implement something like that, we have now the idea of automating it with an RPA tool. Yeah, the first thing in this whole process of getting it live at some point is the requirements analysis. So this is usually start of everything what we do. And yeah, for this specific exercise, we then need to find out what is that person and what are the different people in this whole process doing in these applications in detail. So we really have to find out very, very much in detail what they are clicking, how they are logging in. So we will, we will do something like a time and motion study, or we do even do screen recording to figure out what exact steps someone is doing. So figuring out this process in detail so we won't have any surprises later on, because we need to tell that bot, that RPA tool, very specifically what they need to do. So yeah, I think recording has been proven quite successful in recent projects where it actually, yeah, sits on this computer on a constant base, constantly, and then every click, every step in the process will be recorded and then presented to us to continue with the design.

Yes, exactly. And I think, you know, part of this requirements analysis, what we tend to do is, like you said, we would look at the stakeholders. Now, In this particular example, we only really got two stakeholders. We've got the person that does the review of the transactions and the person that will key in those transactions in the finance system. So for us to do a time and motion study would be really easy because all we need to do is ask these people to show us what they do. And then once we've got that information, and of course what we want to do is move that into a design phase. Now again, the requirements analysis and design phases are not very long-tailed exercises with Insight RPA. These are very, very iterative, very to the point, very fast-moving sessions you have with the users. You know, sometimes you could actually get to a design after you've done your requirements analysis within a couple of hours because you literally just look at the video of what the person does, and that actually sort of just brings to light all of the requirements. Now, the design is still important because we want to look at this and still map out the process with the view for that user to, to actually look at it. We can run through the process with that person, and this could be in, I guess, a tool like Visio or any, any, any tool that you can create or draw a flowchart in. Would be suffice. And in this instance, our design will be quite simple, but it could represent the 2B process. And it will simply have a box that says, well, this is the start point. The first thing the robot will do is it will log on to the time and expense management system. It will download the transactions, perhaps for the previous quarter. Once it's downloaded that, it would perhaps save that transactions somewhere in a location. That the robot then can use to open that up. And then for each of those transactions, there will be another action to look at the transaction, apply some business validation or business rules to it to do the auto approval. If it can't approve it, it needs to do something with it, perhaps flag that to a user. And if it does the auto approval, then the next step in the process is to key it into the finance system. Now you could represent that very clearly with a, with a flowchart, and the idea of the design is to again model that to-be process with the view to go back to the user to say, we've captured your requirements, here's the design, are there anything else in this scope that we need to consider? And usually if you've done the, the design and requirements analysis well, The answer will be no. And then from that point you could jump into the development phase.

Yeah, so before we go into the development, I had one thought. Although this, this is a very small example, would we at the design phase also look at the technical design implications using maybe 2 bots or 3 bots? Will that maybe make a difference for us when we go into development and rollout?

I think for this particular example, because it's such a rudimental example, that will probably be just a very light-touch discussion. But I think for more complicated examples, a technical design will also be appropriate because let's say, for example, that you need, you know, access to additional systems, you need perhaps another database to store this data temporarily in. These are all technical discussions that needs to be held. Now, I don't think the actual end user needs to know about this, but again, you know, in our— the 9 Steps for Successful RPA in our previous episode that we talked about, at that point you would probably engage a technical person in IT to discuss these technical requirements and, you know, come up with this technical design just to make sure that from a governance and a compliancy perspective, what you build is actually going to be something that's compatible with, you know, the compliancy with inside IT, something that they can support. Because ultimately, if you hand this over and it's managed by IT, you know, you need to kind of stick to the rules and build it so that they can accept that and support that.

Yeah, I think that already is something as well before rollout when we go into development, isn't it? So there might be even already some rules we have to follow actually getting started with the development which are already there. So in the previous episode, we talked about sort of getting started. Now if we have it already, inside the organization. There might be already some rules on how to build this next process, what kind of design structures we should follow when we develop that for automation in an RPA tool. Yeah, so you could choose whatever RPA tool you have chosen in your organization, could be UiPath, Blue Prism, or any other sort of capable RPA tool. And yeah, so when you look at the development, you obviously take what you have received during design phase and what you have received in terms of videos to sort of guide you through the actual flow, what the robot needs to take to get this all done. So what you usually would do You would cut this in pieces, isn't it? So in lots of little steps, because some of these things are repeating. For example, a login into a— login into a system is always repeating. So you would, you would sort of create this as a small module and like little Lego blocks you prepare. So this is what usually happens at development. So all these activities will be sliced so they can potentially be reused very easily. And yeah, and then you will follow, you follow through the whole sort of the Visio diagram until you have mapped everything as well in your RPA tool. And in your, you do your typical development testing constantly. This is the nice thing with RPA, you can immediately see what you have developed in the, in the final flow, isn't it, in the final application. You can immediately test that login, does it work? You can immediately go to this Excel export step, does it work? I think in this example, Arno, how would we do the business logic there, business rules? So if it's simple business rules like if this is above £50, then we don't need an approval, or below £50, we don't need an approval. Sometimes if you're a person, you can identify these rules very easily. Where would we, how do we map out these rules the best way?

Yes, I mean, fortunately with all of the mainstream RPA tools, they have got the ability to configure rules with inside the designer. So similar to how you would create a flowchart, I guess, within Visio, and you have lines connecting the different elements of a flowchart to produce a flow within UiPath, for example, you can actually put in those conditions behind the lines to say, if it is below £100, for example, then just apply auto approval. If it's above £100, do something else. So it's got, it's got a very, very easy capability to configure those rules with inside your process.

And yeah, I think to complete that development step, yeah, I think it's all about testing, testing, testing already at that stage before you, before you actually hand it over to someone else in the business to, to have a real go at it.

Yes, that's right. So I think the next step, you know, we've had our requirements, we've done that, we've done the design, we're happy with our development output. So the next stage is really just to roll out or deploy this robot or this particular sequence. And once we roll that out, typically what we would do is we'll will roll that out to a test environment. And that's typically the first time the actual end users would get their hands on it and look at what it does. If there are any change requests or any issues that, that's with inside the robot that needs fixing, you would typically do it at this stage. Also, you would schedule user acceptance testing. So you might have a wider audience because now all of a sudden, you know, we're not going to have a person manually downloading a time and expense spreadsheet from a time and expense system. That's all automated. So, so obviously you need that user acceptance testing to reflect what the new process will look like. And those people will, will basically adjust, I suppose, the way they operationally then work, because obviously this is going to affect how they, how they work. You know, they don't have to do, do that step anymore. And the conclusion of, of, of the rollout is simply where you've got sign-off. People are very happy that this robot does what it's supposed to do, and then you know, we move into the next stage, which is productionization.

Yeah, I think, yeah, there's a bit of trust before, before it goes into actually going live. This is very typically, especially if people are not involved in the process anymore. So yeah, they, they, they really struggle very often with the, with the trust. Can they trust the bot? Can they trust the bot or not? And yeah, so this obviously ideally will all be sort of completed and done in the testing. And then, yeah, if that goes all well, then yeah, we can really get ready to roll this out into production, set our go-live dates, and get everyone excited. Yeah, and obviously before that we have to collect all that sort of dependencies which are part of that implementation and the development, package it all up, create all our release documents, liaise with IT again just to see if we followed all the rules, get approval from them as well that we can go ahead with this. And then we will use all the deployment features of our tools to move this into the production environment. And then very often this is the first time we can actually really work with the production system. Ideally in the UAT phase we might have a very production near system. But yeah, so this sometimes is quite exciting to see it running in the production environment, maybe with more volume suddenly, which could as well lead to some bugs. But then I guess we move into sort of the support at that stage.

Yes, that's right. So once your production, your productionization is done and your robot is successfully deployed and it works, you would obviously move into the support phase. Now, just post-production deployment, you would have something what we call HyperCare support. HyperCare support is really where somebody is available should there be an issue, to really jump straight away on it, fix it. Because you mentioned perhaps volumes which will be different in production than, say, UAT. That person can then resolve that issue very quickly, apply the fix just to ensure that there's, there's not a knock-on effect, you know, where there's disruption, for example. So the hypercare is something that, depending on the size of of the automation sequence you built. For something like this, it could be probably a couple of days. For a larger project, it could even be a couple of weeks. But again, the aim of that is really just to monitor the robot, make sure that it does what it's supposed to do, it's stable, and then to transition it into BAU support. Now, BAU support is typically the business as usual support, where we've proven the robot works, all of the issues in production are sorted, it works fault-free. All we need to do now is just hand it over to the support team so that if the end users have got a support query or there's something that the robot is not doing, then obviously they could raise a support ticket. And that will then be addressed by means of the normal support procedure with inside an organization. Again, a lot of organizations are different, but this is a very typical way to deploy, you know, a very simple RPA process. But the principles are the same for larger projects as well. Of course, your development phase will be a bit longer. You would carve it out in different sprints. You might do partial releases as well. So you probably wouldn't do a big bang approach where you deploy the final robot at the end of the project. So there's various ways that you could get this value in front of the users very quickly. Yeah.

And then I guess we just continue the journey similar like we had last week in our 9 Steps to RPA Success. So once this is done, obviously customer Customers within the business and users, end users will not be shy to give feedback usually. And this is maybe the starting point of a wider rollout of other stuff. So people get excited. So then this excitement usually suddenly moves into other departments. Everyone wants to have a simple process automated like we have discussed now. And yes. Then we get into this nice cycle of ideas, then again repeating the whole process, getting more and more solutions into the departments. Yeah, and then you're in full flow.

Yeah, exactly. And I think what we see as well is, you know, we talked about in a previous episode about, you know, rolling out a pilot just to you know, go through all the steps of actually getting your first RPA robot deployed. Once you at that milestone and perhaps you've got a second robot that perhaps this simple example that we've explained, and as, as you, as you sort of gain more momentum and the, the value of this becomes evident, like you said, Sasha, a lot of people will look at it and say, well, we've got this other problem, it's not time and expense management, this is invoice management. It works for time and expense management, so it's going to work for invoice management. And all of a sudden it just snowballs and those ideas just keep on coming from various people in the business.

Yeah, so if that's the case, that's fantastic indeed. But if this is sort of just one process someone identified in the business and then this is the end of it, no one has any kind of not— what is the word— any inspiration, then there could be other technologies out there who can then build the pipeline for more and more RPA activities, something like process mining. But this is something we can talk a whole episode about.

Yes, I mean, they're— that's if you look at the the maturity of your RPA program. You know, I'm always of the view that you start small with these things. It will organically start to grow into bigger initiatives. And as your RPA program matures, then that's your opportunity where you've already proven value to the business. The business has confidence in the fact that you can deliver this value. And then you could actually go a bit wider and say, well, now we can start to deploy more sophisticated ideation tools. So the process mining. So rather than looking for processes by speaking to people or asking people to come forward with their problems, you actually go look for those problems using process mining. And all of a sudden there will be a very big project pipeline that builds up, because typically process mining is something that highlights a lot of issues inside the business. The danger sometimes to start with process mining is the fact that there is so many problems and you don't really know where to start. So I'm of the opinion that perhaps start small like this, solve practical problems for people first, and once you build momentum that's when you actually start to perhaps use, you know, some of the bigger tools to fill up that, you know, project backlog for, for the potential automations. And then also other progressive tools. You know, we spoke about artificial intelligence in our first episode of this podcast when we touched on demystifying hyperautomation, you know. That's something as well that, that could potentially be brought in as, as you, you know, go along your RPA journey. And some people decide to bring that in up front. It all depends. You know, again, my view is start small, and then as you prove the success of the tools you use and the, you know, the cost savings you're making You know, then it gives you almost that confidence to go out to the business and say, you know, let's be ambitious now, you know, let's look at the AI tool to, you know, do some of that intelligent decision-making that a human will do, for example.

Yeah, great. Yeah, thank you very much. Yeah, I think that's very, very good, starting small. And if you ask, usually if you ask people in different departments, what they would sort of give over to a digital helper, little helper, if they would have one. They all come up with lots of activities, and I think this is a good starting point as well. Unfortunately, that's it again with this episode of the Process and Automation Podcast. If you like this episode, please give us a 5-star rating And don't forget to subscribe to this podcast so you don't miss any upcoming episode. We hope you will tune in next time. And until then, let's automate it.