When starting your RPA and intelligent automation journey your team will inevitably come across some or most likely all of these challenges – let’s discuss how to overcome them, and potentially minimise the chance of them arising
Missing or unavailable data
When it comes to running successful RPA programmes, data is key. You want to measure whether the opportunities you’re exploring are worthwhile, and you also want to prove that benefits from the change have been realised.
Missing or inaccurate data gives a false view on the potential savings or return on investment of your automation incentives. You want to measure the weekly volumes and average handling times for each process as accurately as possible, so you can calculate the amount of FTE (full-time employees) effort these processes use, which will allow you to start prioritizing your opportunities.
It’s best to collect sample data and observe the process to sense-check the metrics. Some teams don’t collect data like weekly volumes or AHT (average handling times), and sometimes it’s difficult to extract data from the system. Also, unless you’re in manufacturing, it’s generally frowned upon to walk around with a stopwatch to time staff on how long their processes take to complete. To get a rough idea of AHT your team may have no other alternative but to ask several subject matter experts (SMEs) for their gut feel, however, recording the screen as staff carry out the process would be better
Staff’s resistance to change
One of the biggest challenges is resistance from staff who may be directly affected by the change. If they can’t see how it benefits them, why should they be interested? If they feel their job could be at risk, why would they want to cooperate? A good communications plan can mitigate the resistance, and conveying opportunities to upskill or re-deploy staff alleviates fears of being replaced and shows staff they are valued.
Getting buy-in should be first on the agenda and maintained continuously. You can keep staff involved with regular lunch-and-learns or periodic workshops that makes staff aware of the technology and shows them how to get involved. Keeping the door of your Centre of Excellence open and continuing to communicate with staff can relieve many tensions about introducing automation technology.
Loss of traction
It’s great if you have made a start by rolling out some POCs but perhaps things have gone cold and stakeholders have lost interest. If you’ve lost traction it could be because you’ve made the same mistake that countless other businesses make: you’ve tried to solve a really big problem or your team have chosen a very complicated process. These opportunities take far too long to deliver. When starting up, you need to deliver some quick wins regularly, mixed with some good-sized opportunities to get the momentum going. I’ll show you how to choose the right mix of processes to start with and how to prioritise the rest
No clear governance
If there are no checkpoints or no gated process, and roles and responsibilities have not clearly been defined, then no one is accountable for each step of the progress. Your project is at risk of going around in circles or halting all together. Having clear, written governance that is agreed by all parties upfront, and with senior sign off, is the only way to avoid this pitfall.
Not only do you need to know who is responsible for each part of the implementation process, there needs to be an agreed turnaround time for each step. Assemble questions such as ‘How long should it take to get robot access to applications, or for the Process Definition Document (PDD) or Solution Design Document (SDD) to be signed off?’ and ‘How long will it take for the bot to be handed over from the developer to the support team?’ Also consider that at each checkpoint or gate you need clear acceptance criteria.
Process clarity
The PDD is the most important document in this whole process. This is what translates a business problem, into a technical solution. RPA business analysts must manage the relationship between the SME & developer, so that the developer creates a bot that does what the business wants.
Its important that the process steps are well documented at a detailed level, showing the clicks and keystrokes the robot should make. The developer will most likely be unfamiliar with the process so there must be no gaps or jumps between one step and the next.
This document must include everything the developer needs to effectively become an immediate expert of the process. The developer needs to know:
- Where the bot takes the information from
- How it will receive it and in what format (e.g., what is the folder location, website address or email address, and will it have a specific subject title? Will the file be in xlsx or pdf format?)
- The precise format of the data (e.g,. what type of data is in each field, what is the file naming conventions are, and other data integrity information).
- What the bot must do with the information
- Where or to whom to send it.
- What time(s) the process needs to run, what days, and if there are any service level agreements (SLAs). This may determine whether multiple bots might be needed to process all cases in time to meet the deadline.
We take a closer look at the PDD document structure in the book Business @ the Speed of Bots
Documentation can differ from reality.
This links to the previous point. A major faux pas of your RPA team would be to rely on work instructions and other process documentation to design the automated process. What’s written down tends to be quite different to what actually happens. There are 2 simple reasons for this:
1. Work instructions are usually written by the experts who know the process inside out. This is susceptible to ‘the curse of knowledge’, which means assumptive leaps may exist between steps, and the author may automatically believe this to be obvious.
2. The team or individuals might have found potentially better way(s) to do the process after the instructions were written. In lean thinking, the best way should be the standard, so maybe it’s time for the team to find out which team member is the most efficient and use that person’s knowledge to update the formal process documents.
To avoid this pitfall, it’s always recommended to walk through the process with the SME. Shadow the person to observe how the process is executed in practice, so that your RPA analyst can fill in any gaps identified in the documentation.
Test vs. Live (Production) Environments
More often than people want to admit, bots can act differently in the live environments than they did during testing. There are several reasons for this but mainly it’s due to the application versions in the test environment being slightly older to that in the live environment.
Even if you have the most updated version in test, the bot may still act unexpectedly for unknown reasons, hence why a two-week, live test period is advised (or longer if the process is a high-risk, high-impact process such as one involving finances). During the test period the developer and support team can watch the bot closely and immediately fix any bugs.
We’ll look again at testing the process in both the test and live (or production) environments later on, but ensuring the test platforms have the most up-to-date versions to match the live environment as close as possible can minimize risks.
#rpasuccess #digitaltransformation #rpaimplementation #artificialintelligence
You can learn more about implementing RPA (Robotic Process Automation) and intelligent automation at Leania.co. On-demand Consulting
You can read about these tools used in the AEIO YOU method in their new book Business @ the Speed of Bots, How to implement RPA that scales
