Robotic Process Automation Projects (7,250 words)

This is a transcript of the BA Video Series Linkedin Live webinar on Robotic Process Automation projects

You can also listen to this video via the podcast

If you are a business analyst interested in accessing more of these topics, then join the BA Video Series now! and sign up to the product updates: www.bavideoseries.com

Speakers:

Simon Board

Jason Warner

Vijay Nair

Intro

Simon Board:

Hello and good morning everyone. My name is Simon boards, and I'm going to be your host for today. but before we start, I just wanted to remind you that we do these live streams every Friday at 9:00 AM. So just to keep it in your calendar. We look forward to seeing you every week. And also just a reminder, you can also join our BA Video Series group and you'll get all of the updates and previous videos, through there.

I also want to say we run these kind of collaborative sessions and today we're going to talk about, RPA. I want to introduce quickly our guest speakers for today. So we have

Vijay Nair:

I've been working for the last 10 years on a wide range of projects and, not just as a business analyst. Even before I got into the business analysis field seven years ago, I was working in web designing activities, a little bit of development activities, in IT departments managing infrastructures, e-learning or online training activities and managing educational portals. The last seven years was quite an interesting journey for me because I had an opportunity to work on a wide range of projects from big data, Business Intelligence, RPA, 3rd party technologies, etc., but a lot of this involves working with technical teams and implementing solutions.

I'm looking forward to talking a bit about my RPA experience.

Jason Warner:

Hi everyone. My name's Jason Warner. I'm the capability lead business analyst, for a large nonprofit in the United Kingdom, my experience ranges from process analysis through to delivery and business analysis.

We've just started our RPA journey. So it's been a really interesting project, and excited to talk through where we've got up to so far. We've currently been working on a proof of value, using one of the technologies. I'm sure we'll speak about, in this group. but yeah, my knowledge is a little bit limited with RPA.

We've gone on a maturity journey, throughout that stage, which has ranged over the past year. So, keen to, learn from Vijay's experience and also share my own as well.

Simon Board:

Brilliant. Thanks guys. That's really good. So just to introduce this session, today we're going to be talking about RPA.

And for those who don't know, RPA stands for robotic process automation. So looking for a couple of definitions here to define what we mean when we're talking about RPA. And the best one I could find, is, that RPA is an advanced form of business process automation. This is able to record tasks performed by a human on their computer, then perform those same tasks without human intervention. Essentially it's a virtual robot copycat. We also have another definition just under that. Put simply the role of RPA is to automate repetitive tasks that were previously handled by humans. The software is programmed to do repetitive tasks across applications and systems.

And the software uses a workflow with multiple steps and applications. So that's a little definition of RPA. So purpose of today's session, share our experiences. Vijay and Jason will talk to you about that in a bit of detail and their experiences.

Project Experiences

Vijay Nair:

Yes. thank you, Simon. So, I thought I'd share my story, which I think our audience would be really interested in knowing. So a little bit of background, the RPA journey for me started when I was, with my previous employer.

And, we were doing, automation projects for a banking sector, specifically, a bank somewhere in the remote areas of Scotland. And I was still in London at that point. And I still remember the first few days, when, when we started to get involved in this project, I mean, we were a group of consultants, and we had to take this budget Adeline from London to the sort of more, a part of Scotland.

And, as we entered into the headquarters of this bank, basically, I mean, it was great. We had great greeting session that with, the reps, the, with the bankers and, quite a few intro meetings we had with that. But. There the first week or first couple of weeks was actually spent just understanding, having dialogues and understanding that the, understanding the processes and the, what people are working on or what wrong.

So, I mean, we had a few templates that we were working with when we started identifying the processes and I'll go through this checklist. So hopefully it'll make sense. So the first thing we did. Is, we have to use something called us the process assessment questionnaire. The purpose of this questionnaire is to actually understand what is actually happening right now in the process.

So in now, in this particular, project, along with a few consultants, we were looking at the non-management system, for this particular banks. So mortgage loans basically. And the mortgage process itself is quite complicated. As most people who own properties they'll understand the experience and how difficult it is to get mortgages and, you know, get that a good, even from the banks.

So we have to go, we have to really go to the nitty gritty level to understand the as-is process of you. Okay. And using the questionnaire. So how, how it happened is that we actually have to sit next to the, the staff, literally sitting next to the staff to look, to watch each and every process, that they are clicking.

So they, they might be using one or two or three systems out there in the, you know, in front of them, in the, on, on their desk. And. One of the key things that we realized is, you know, there are so many systems dependency systems that they have to use, as part of their manual, you know, doing the whole process of producing loan letters and, you know, the whole end to end process.

So that's why we needed so many consultants in this political project. Each consultant was in charge of looking at just one piece of the puzzle. One, one process among many other processes. Like for instance, producing the loan letter. you think the producing a letter in malls, just writing it all and it's all done industry, but the reality is there's quite a few automated, quite a few legacy steps happening over here in the process.

They have to click from one webpage to the other webpage, you know, in the series of clicks as consultants, each of us have to be in charge of each process. And each of us were sitting next to the staff, observing. The click-by-click, approach of what the staff was doing to produce the end product.

In my case, I was looking at the loan letter and how that was producing the chain of process. So I have a few notes a year to do identify some of the key things I had to ask in the question. First of all, what is the process name and the description? So a quick summary of what the description is for this person in this case, producing a loan letter.

Where does it align in the company? So in this case, it's a banking sector. They've got so many other products that work. Where does this process for the big equation? Total ft completed, for the process. So this is a very important thing in any robotic, RPA project is I it's doing a calculation of the full-time equivalent to complete the tasks.

So FTE, in many organizations, the managers who are managing these teams. Have a great insight into how much ethical what's the activity FTE like to complete the process. So in my case, there were three FTEs required to complete the manual process. So I got this information from the manager, but also from observe, from speaking to the staff who was working in process, I, I managed to, To figure it out, you know, from this information that, yeah, it is three FTEs that's required to complete that, that one single process, no FTE.

It's one also noting in that an FTE, when you're doing the calculation here, you need to only look at the total time it takes for that one individual or not even one individual, but the total time it takes. To complete that one process and you should definitely not include break time or lunchtime.

You know, the nine to five, you can't just say it's nine to five. That's the total time it takes to complete a task. For a date, because that could include the time it takes, you know, lunch breaks and all these other small, small things, all the quantization or the meetings that you go into with your colleagues, you can not be including that in the FTE calculation.

So. You got it. That's why it's very important to have this conversation with the staff and really break it down as they talk about how much time it takes. So there's a bit of ft calculation. The percentage team time spent on process per day. That's, that's also important average daily, weekly, monthly case.

So in our case, how many, how many times are we using this process? So producing the loan letters. So you could be, producing 10 loan letters in a day. W we need to figure out what's the, what's the deal for, for doing that assess and accordingly, figure that out for daily, weekly, and monthly.

What is the average handling time per case. That's also very important. So we need to figure that out. What's the, how much time does it take for one piece to be done? And finally, what's the average exception rate in this process? So that again, when we use the word exceptional here, it's worth noting that the technology that I use now in this project was, blueprint, which is one of many, RPA tools out there.

And for the, for the purpose of using implementing blue prism, we actually had to find out what the exception rate is. So exceptional year is. Anytime in the process, a human being needs to come in and do further investigation. So in our case, the loan letter production process, you could automate the click by click or keystroke as we call it the keystroke actions to complete a process.

And then at some point. Someone needs to revise the letter, make sure, we are including the details of the mortgage lender or, you know, all of those, the broker, all those details. We've got to include in the letter and we've got to investigate to make sure that there is any problems there. So that's an exception.

So the, when you implement a robot, the robot has to throw out a few exceptions where the human being has to do some problem solving task. Which is not a rule based, but it's rather than exception. So in RPA terminologies, we distinguish between rule-based approach and the exceptions rules are the part that the RPA part can automate.

And the exceptions are the bits that you've been set to, looking to, to investigate. We also have to look at the dependency systems. what's what other systems is, is this process going to. You know, touch on and interact with. So we got to look through all those, all those processes. also it's worth asking the question, which is, are there any foreseeable changes that would have happened in the process that they have right now?

It could be that they've got an innovation project in the, in the horizon and they need to introduce that into this. into this delivery. So we need to take that into consideration. So finally, once we come up through all these, questions, this is our process assessment questionnaire. We've got the whole details of here.

You also have to identify what is the rules, what is structured data and unstructured data. so structured data is, is rules based on structured data, which is the assistant clip by clip approach, the unstructured rude. Is like, it could be, you need to scan a document. you know, so you need to, even though it's not a human intervention, but the robot needs to, if it's on the same device or same machine, the robot needs to use its own, algorithms to, to scan a document and send it out to an, as an attachment, to an email, to a mortgage advisor or whatever.

So. Those are structured unstructured rule-based processes. So again, we've got identify those things. So then once we did this, we finally were in the position to document what we call it as the process definition document. And this process definition document, starts off of it. Everything that you gathered so far from observing staff, doing the job.

Everything has to be documented in an format. So the first part is the manual process of a good lengthy manual process that identifies what's a to Z activities for that one particular process. Then, along with that, we also have an as-is process metrics. This is where the volume metrics is so important in the RPA implementation.

So the monthly volume case handling time, estimated exception rate, peak volume. That means, so you've identified that this one process, it produces, I mean, you might be doing this 10 times, so 10 cases for that one process a day, but say in the end of the month, because it's payroll time, suddenly the volume has increased, so it might be 20 cases.

So we need to find out what's the highest number of cases and not just assuming what the daily count is. Like. We got to ask that question to the staff and identify what is the, if they have an allergy to use that as well. But what is the highest amount of cases that you're going to be doing this, process?

So we've got to capture that. Now, finally, once you got the metrics, once you've done that, you now start documenting the narrative for the automated process. So again, the automated process description. So, so this is basically the two B environment we need to figure out what's the, to be going to be. Now that impacts on the assets.

What's the tubing. The tubing is based on the questionnaire based on what you've discussed with the staff, how much of it is room space and how much of it is exceptions? That's what we are. I mean, normally what we normally do in this process is we actually started a Vizio, a process flow diagram to the assets process flow item.

We just analyze it. We go through it with our staff, the process flow diagram, how much I would of this. The rules are rules. And how much of that are exceptions. We look at that diagram at the rules spot. That's where you realize that this, this is where the RPA comes in. Let's let's include automation in those rooms over there, and the exceptions are what the RPA robot is going through.

It's worth noting that because we were using blue prism, blue present costing is different to other applications, in the sense that they normally charge you on a per robot basis. So that's why it's so important to get nitty gritty details on the bottom metrics and everything, because you need to understand that capability of one single blue prism robot, how much.

How much, can one single robot handle. And because blue prism charges its clients by the number of robots that you purchase, we really need to, as consultants, we have to really squeeze it. Just the enough processes. That is necessary. That's why it was in our document. We also have to look at what is in scope and what is out of scope.

You really have to be perfect in including what is in scope and making sure that that is really what is in scope or not, because it all comes down to the cost and the budget that the company's ready to pay for. So a little bit of this have to happen as well. So you look at that as start documenting your process flow for the two B environment, your two B process flow with the automation in place, your narrative.

What's the automated process description going to look like? So FTE is an interesting part of the year. So now that you calculated say three FTEs in the as-is, how many FTEs do you need? Two in the two B environment. And this is where we need to, this is, this is where negotiations happen. There's no simple rule of you.

You got to apply some logic into how to, how to do the countdown of ft. So in our case, we realized that the TFTs, we were able to. Minimize that to one FTE, that this robot process, there were quite a few calculations. I haven't included all those calculations are, but it's quite a unique to each project that you involved in.

So you need to, you know, the assets at T and then now you have to figure out what the new FTE is going to be after the implementation of this, RPA. So again, in this automation, you have, the process, the process name, the, the maximum potential benefits. So this is a very important, so what do we mean by maximum potential benefits?

so what we mean by that is in the ideal situation, when you implement the RPA tool, we have zero exceptions. That would be the ideal situation, but the reality is much different. You will still need some human intervention in some of these processes. So in the loan, in our case, the loan production and producing the loan letter, we still need one person to review the contents of the letter and includes some additional bits after doing some investigation.

So these are exceptions. So we managed to figure out that the maximum potential benefit from RPA was 80%. So only 20%. Is thrown out as exceptions, which needs the bit of human intervention. Yeah. And then also I, document your dependencies. What are the dependencies systems in this process? Definition document, the risk of process failure and list of her exception reads a reason list.

You know, so these are the list of exceptions that the, in the overall process we are going to identify. So it has to be documented this stuff. Now, once you've done this, there's a bit of tangent. I've spoken to a couple of other, I was lucky enough to speak to a couple of other RPA experts and designers.

Who've been working in the RPA field, outside this forum. there's there seems to be, not a single, I mean, there's not a single definition in terms of the difference between a process definition document and a proof of concept. So in our case, when we started documenting this process definition document, it's served to be as a proof of concept as well, because this whole document was then fed to our RPA developers who now.

Apply the logic in the bloopers and, business objects, I believe it's called. So you start writing the process, documenting the processes on the automation tool and, you know, connect doing all the connectors, setting up the environment for it and setting up the robots to work through the logic. or they use some, they have business studio and process studio underneath.

You have these different processes and you've got to go through this sequence one by one. So it's not a universal agreement that the POC and the PDD are, are diff different documents. So now case. We use two different documents, but in, my colleague from cap Gemini, when he used this, maneuver was involved in this process, they had two separate documents, the PDD doing this and the POC, he practically called it a sprint zeal.

Of this document. So that means you're in an agile world screen. Zero is when you're starting the user stories. And, you know, you're, you're preparing the user stories to be going into the next, into the sprint one where it's starting to be developed. So that's how they looked at. But in our case, we, we combine the whole into two into one document and call it.

This is our PDD and our POC that there's some jargons on there that people. No look at it quite differently in terms of those terminologies. But yeah. So once, once, once we were there with the document, I think a lot of the business analyst after desire, I kind of, I think kind of stops at this point, at least with the documentation part.

So now it's, it's a matter off. The creating that logic using blue prism and building the whole building the whole setup, in a test environment. And the way to see the success of this is you build, you go through the document. You go through the process flow diagram and build your logic on blueprint.

And now start. working in a start, building the logic and putting it in a test environment and getting the trial users to start, testing it. In our case, the trial users, more the, the staff who was, you know, who will, who will be interviewed in the process. So they will our first, tri users because they had to go through.

To check the logical. Correct. And we haven't made any mistakes. So start small is how it, how is the advice given you start small with a single process in terms of implementation, you can do all the documentation, simultaneously balance, but when you start implementing, start it with the, with the most tiniest process, that can be automated.

Do that, test it out with the, the, the, the staff that are using it. and it testing needs to be in the form of, you know, Yeah, taking it seriously. Like this is what they would be doing on a day-to-day basis so that you can get some really vital data in terms of how they are using once you, once there's a success and you can get some feedbacks out of it, you can put it back into the business logic and redo the logic depending on how they're using it.

This, this kind of customer feedback loop is used. And this is how the next sequence of RPA processes. I believe that was the, my experience of into end of, implementation of the RP project. there is also another project, but I'm not going to take you back, but that other project was, was more about identifying where the RPA was, the right tool or not.

And, for that, it was more and more doing the, this was an insurance project and over there it was more and more doing it as it is. doing an as-is of the whole process as we did in the previous did the whole documentation. But then at this point we had to give them a few recommendation, optional analysis, you know, option a is.

Range, option is we re-engineer the, the, the tools that they using option B is creating a web design web application to automate some of these things. And option three was actually implementing blue prism RPA in the oral process. And again, in the end, they figured out it was too expensive to go to RPA and decide to go for option one, just, it was more of a question of source on that point.

Well, of course that's different for different, different organizations. But yeah, that's me.

Jason Warner:

And, so my experience so far has been pretty similar to Vijay's in terms of the life cycle of implementing or discovering RPA,. A bit of myth-busting, which might be useful for some people. Because Simon, I think those definitions of RPA were brilliant, in the introduction. but I guess just to call out some of the obvious ones, which I've had business users ask me the questions, (1.) RPA, isn't a, physical robot as much as I'd love that to be. It's a software application.

It's not a physical robot sitting there tapping away at the keyboard. it works agnostically across, platforms. So it doesn't need specific integration. it works exactly like a human user would.

So, you're not limited by the systems and applications that you work for in your organization. And there's also this concept of attended versus unattended. So you can choose the robot to be fully autonomous and work behind the scenes and work out of office hours, and shed you'll the, the bot to run at certain times.

You can also choose to click a button and say, I want you to run this, this process now and help me out with some of my work. So there's a number of different concepts and ways that you can utilize the variable. so where we're up to at the moment with our RPA journey, And the RPA concept came from a more unconventional place than our usual projects and going down our traditional operating model, it came from, an innovation team, in our organization who wanted to explore, the potential opportunity of utilizing a tool like RPA.

So it didn't come from a more traditional business analysis place. When we took on the project and very similar to Vijay, we opted off to going through an RFI RFP process, to choose blue prism. There are a few other major vendors, UI path and automation anywhere being the other big two.

Others are up and coming and becoming more mature tools that you could choose from. But we chose for blue prism and we also chose to, involve an implementation partner because the maturity and skillset of RPA, in our organization was very early stages. So we needed help with the structure and the development.

So very similar to Vijay. We started with an embryonic backlog of processes. And we actually used our business analysis capability and community to identify some of those areas, that we're currently experiencing. Very highly manual tasks, in the organizational processes that, may be able to benefit from automation.

So we started with producing a backlog of all of these processes and matching criteria against them to help us inform, prioritize what processes would be. A good candidate to take through to a proof of value. So we ended up choosing, three processes. and there's short of criteria that we're talking about here is, what sort of volumes are we talking about?

Are they high volume, low volume, high risk, low risk? do we have the skills and knowledge that dedicate from the business teams, to help with the RPA implementation? do they involve some of our core. Systems which align with our automation strategy, or are they working on smaller systems that may be able to be resolved with other types of automation?

So we settled with, these three processes that we were going to take, which we have taken forward, in fact, so they, they range in that right. Diversity. So one is, inputting, offline payments, into our CRM system. We receive approximately 500 rows of data in a day, which is all manually keyed into our CRM system.

We also took forwards a cleansing process and address cleansing process. in the charity sector, we have, you might be familiar with the term gift aid claiming, where proportion of a donation, can have a form of relief against it, of, of financial relief against it. and in order to. to have that satisfied, it has to come from a residential address.

So this cleansing process is about identifying addresses that either fit into a residential address or fit within a, a business address and being able to filter. those addresses out. and the third process is a thinking process. So if someone has made the donation, we, we send out a thanking letter and it's about merging all of those letters from our CRM system, into the associated.

letter templates that we have. So those were the three, processes that we had, and very similar again, the identification and how we went through, not choosing the process, but identifying it was similar to Vijay. So producing this process. Definition document was a critical part of building the requirements up.

So we worked with the implementation partner, and the business teams to sit down record and go through step by step each part of that process, along the way, identifying what the exceptions and variations are when you record, Humans and you record an understand that there's a team or a group of individuals completing that task.

They may all complete it in very, very different ways. And there are exceptions and variations of how those tasks are completed. So keeping to those rules, as Vijay was saying is, is incredibly important than being able to identify. The exceptions, which you can build into the tool and say, we want to validate against these exceptions, but we can also make, we may also want a human to intervene.

And therefore we're going to pull that out as an exception and let, let a human glaze over it or, or look over it with their own eyes. So I think that that, project definition document, is an incredibly useful tool to validating that we've captured the process correctly. And it gave a really good visual representation to feed back to the business teams to say, have we, have we captured this in the right way?

and it's. It sounds, maybe more intimidating than it actually is. In our case, we recorded, we screen recorded the processes. and we followed that up with, we followed that up with, some screen grabs in a, in a word document, and a step-by-step yeah, the step by steps of the process as they occur in sequential order.

I think then at that point, we started thinking about the measurements of the benefits and baselining, the current performance levels, of how long the process takes, what parts they are doing. And, you know, I'm not going to speak, go, go through all of this in too much detail. Cause I think Vijay's captured it incredibly well, with, with, his breakdown, but again, a very similar journey.

I think the only. Other thing to mention, on the implementation is that the output of that, was creating our solution design document. So similar to the PDD, given a visual representation of what the process is, the SDD was the, the captured design of the, in this case, blue prism on. How that was built, what objects were built and by objects, I mean, in blue prison where you can record, the different parts of the process and group, group, those steps into an object, which can actually be reusable.

So for example, if you're logging on to a CRM system or you're logging on to an application that could be. An object in itself, which therefore wouldn't need to be redeveloped. You could reuse that object and push that into another part, another process. so baselining, those, those benefits and understanding where the.

the performance level set with the business teams, was really, really important because that's going to allow us to realize the benefit of RPA if there is any, which I'm sure there will be. seeing the development go through and understanding the performance of what blue prism can achieve.

There's definitely, high benefits there. It's also worth mentioning that the SDD document is, is IP and it's is the intellectual property. If you're working with an implementation partner, that's effectively the output of the project and that's incredibly important. You know, you can use that to knowledge share across other organizations.

You can use that, to communicate that development work, with, with either the business teams or the technology teams in your own organization. and you can use it as I said, to, be reusable in other parts, if there's, if there's parts of that process, that are, that can be reused in other processes.

So I think some of the lessons learned for us so far, and that there's, there's quite a lot, you know, being on this relatively immature, part or stage of the process. I could say that we've learned so much. So one of the big things is, the focus for us wasn't necessarily around head count reduction and, and removing resources.

It was actually freeing up, People's time to spend on more value at work. And I think that that's a really, really poignant point in, because you need the buy-in from business teams. If you. Almost go down this journey of saying we're going to use RPA to, stop, you know, making it a headcount reduction.

It's going to be incredibly difficult to start getting buying from business teams and they're are going to be a key factor in the success of scaling and implementing golf PA. so I think for us, the focus was definitely around. Value add work and freeing up, time from the business teams. I think another important lesson is making sure that the processes are fully optimized before they're automated.

Otherwise you're automating an inefficient process. and that was something that we learned, learned the hard way. and again, that should fit around an automation strategy, but making sure that, you know, you're going through the right. Process improvement lens to make sure that the process that you've chosen to automate is fully optimized before you even think about development, understanding the volumes and this, this fits in heavily with, what Vijay was saying about the licensing, of the, of the RPA bots.

the RPA bots are done on a license basis that basis, and they only have a certain. capacity, that they can process. We took three processes forward, and only bought one license. So the scheduling suddenly becomes, a bit of a nightmare because you've, you've suddenly trying to squeeze in.

and at this point, You know, we weren't in a position where we knew how long the timings were going to take all the processes and was going to take for each one of those processes. So we're trying to schedule in and assign dedicated time towards each one of those processes in a 24 hour chunk. At least that's what we thought.

We thought we had a 24 hour chunk. and I think that this is another one of my lessons learned, which is. our initial perception was RPA was a 24 hour machine that could run, you know, effortlessly over seven days a week. And in most cases, that's, that's probably a fair assumption to make. but again, what we didn't allow for is.

any downtime, so where there's updates, security, updates, and patches that are happening, are there any updates that the blue prism bot will require to have? That's going to need some downtime in it. So when you're doing your scheduling, if you only have one license, that's a, that's a really, great consideration to, to take forward.

I think, one of the pain points, around the implementation, Which we experienced, was around the permissions and the access that we could provide. the, the bot, we, we had that mirrored, the, the accounts mirrored from the business teams, but we found in lots of instances that, The access that the bot required, wasn't always necessarily granted.

And that became a real pain in the, in the development side, because it meant a back and forth communication trying to get the user access for the bot and going back and making sure that the development team had the right access to all the folders and the systems and the applications. So that, that, that could be something that could be mitigated against providing you, give that upfront thinking.

I think the, the pro prioritization of the backlog was incredibly important. that was an incredibly important part of the prioritization, I think, as you think. Of scaling something like RPA. that's going to become a really crucial tool is going to become a crucial tool to have conversations and manage expectations and demonstrate, the decisions that are made to business teams about.

Y, you've put certain processes forward. I think everyone at the moment, as soon as they get a taste or a small flavor for RPA, they suddenly think of about a thousands of processes that they can, that they, they, they could benefit from using gets all like that. So having the backlog to, to enhance those communications and discussions, has been a really important tool.

I think the other learning is around, test data. If you're a business analyst working on an RPA project and you're, you have responsibility for the quality assurance, making sure that you have all of that test data up front, and making sure that you're mapping the scenarios, in a, in a timely manner, ready for RPA developers to test against, This is one of my favorite, lessons actually, which is when you're telling the story, around RPA and you're communicating the benefits.

it doesn't hurt to give, the. What's her name, give it a persona. it does work exactly like a user and it enables people to have, a more, emotive and emotional connection with the bot to actually understand what it does. So in our, in our, example, I mentioned the, the short circuit reference and we've called our bot Johnny five.

and I think that that's just enabled, the business teams to, Help visualize what the bot does, but also give it a more of a human element as well. I think the other thing, and this is one of my last considerations for lessons learned, and it's trying to understand the downstream impact of automating a process.

So using RPA is, is fantastic. And, you know, there, there are so many wonderful benefits that come along with, but. One of the things that we failed to do is try to understand the full end to end journey of the process as a whole. So not just that, aspect of the process for the business team, that the full value chain from end to end.

if you're automating in. With a focus on one particular part of the process and not taking consideration that downstream impact, you might just end up bottleneck in at a later stage. so we're pushing through, let's take an example of our thinking letters. Fantastic. We've improved, the speed of producing those thinking letters and passing that off to the relevant team to be printed and to be, and to be sent out.

But do they have the capacity? Do they have the, the tools to be able to deal with that downstream? If we're increasing the automation and we're increasing that volume, there can be. Consequences and impact of that. So that's just a consideration, I guess, to, to think about which, which we missed out on.

and that was an opportunity missed. And then we needed to think about, you know, that downstream impact what we can now we're going to do for this business team. so yeah, I mean, in a, in a nutshell that they're more or less all, all our lessons learned, I think. RPA is good for a lot of things.

There's also some things that it's not so good for as well. So working on, areas where you may have, skills or knowledge gaps that can be really, really tricky. and like I said, when we were coming up with this criteria, That was an area that we didn't particularly want to focus on. I'd recommend that is a good place to start.

if there's a technology that's due to be replaced, like Vijay mentioned, then that's probably unfit for automation, especially in the RPA world with the exception that. It could help facilitate the transition from an old technology to a new technology, because it's an agnostic tool that can, you know, work in a non-biased way.

You could use it to migrate over a system slowly or pick up any breadcrumb processes that may not be able to be picked up, as part of a core offering of a system. and it may. It may be that you pick up those small little breadcrumb processes, as, as part of your automation strategy, because all of those little breadcrumbs, get built up to, to become a big loaf.

so, you know, there's, there's lots of cost savings, in taking that strategy as well. I must think. That's everything that I had to cover. the only other thing that I can think to mention is, how a business analyst works on an RPA project and how that could be different. and I guess, you know, my involvement was, the.

Enrichment of the backlog and the elaboration of the criteria and the processes that were coming through very much treated like, requirements. Exercise, and making sure that that aligns to an automation strategy, if you have one and if not, it's in the conversation to make, an organization think about their automation strategy.

I think the, a big part was in the collaboration of the development. Of the PDD. So going through with the business teams, the process definition document, and making sure that that's being recorded and liaising with the team again for elaboration and clarity for the developers, was a big part of the business analysis process.

again, the quality insurance part, developing the test scenarios, making sure that the test status there, that's your responsibility as a business analyst. If you haven't got a dedicated QA team, that would be a big part. And let's say the identification and realization of benefits as well. that's when, a business analyst can really play a large part of helping business teams to identifying what their current baselines are, and then helping them realize that business case, especially if you're thinking about scaling, RPA in developing a business case, which is what we're doing at the moment.

Conclusion

Simon Board:

That's brilliant. Thanks very much, Jason. Thank you Vijay, very useful insights. So on that note, we'll sign off and thanks for your time and have a great Friday and a great weekend.

This is a transcript of the BA Video Series Linkedin Live webinar on Robotic Process Automation projects

You can also listen to this video via the podcast

If you are a business analyst interested in accessing more of these topics, then join the BA Video Series now! and sign up to the product updates: www.bavideoseries.com