People often adopt the people, process, and technology (PPT) framework to deliver change. As we know, a balance of the three helps to achieve harmony and drives action. Given that Robotic Process Automation (RPA) utilises technology to automate people-based process, it fits perfectly into this framework.
Before starting the project
Your finance team may fear any proposed RPA project. This is natural given that productivity improvements are commonly identified as the primary objective. More so than in other projects, you will need to think carefully about your strategy. Will some people lose their jobs? Will there be opportunities to re-skill or re-align to higher-value tasks and roles?
It is imperative at the outset to use communication and leadership skills to clearly outline the objectives to staff to gain their confidence and buy-in. Decide how you will change your culture, mindset and behaviour. If you get it right, you will have the team behind you, supporting you. If you get it wrong, you may have created some people barriers that you will need to overcome later.
Identifying tasks to automate
It is essential to understand the processes in detail to identify suitable tasks for automation. What better way to do this than to engage the expertise of staff performing the tasks on a day-to-day basis? Use interview skills to identify the processes they regularly perform, where they spend most of their time and what they wish they did not have to do. This is why it is so essential to get the team behind you at an early stage.
“Once you have compiled a list of tasks, use analytical skills to document the steps and logic behind the task,” says Manish Sharma from Servicetrace, a leading RPA vendor. “Also, take the opportunity to calculate expected productivity savings and the level of impact so that you can prioritise the order of implementation.”
Configuring an RPA solution
There is often a fear that any new software or technology will require external assistance and/or internal help from the IT team. While you could argue that this is a valid argument at the proof-of-concept stage or perhaps implementing the first task, self-sufficiency is commonly a critical requirement. This would apply for much of the implementation of the ongoing maintenance of the solution.
Of course, not all RPA solutions work in the same way. Some RPA solutions rely heavily on simple desktop applications that record the user’s clicks and keystrokes. Others require coding skills to create a robot or complex deployment models to deploy robots to desktops instead of running robots on a centralised server.
If you build an RPA solution around writing lots of code, it will be harder to realise the benefits or the ROI you may expect from automation. Unfortunately, some RPA solutions are intended for developers, not business analysts — meaning you will have a much greater learning curve and more ongoing reliance on IT.
If you want to be self-sufficient, says Sharma, make sure you ask the vendor the critical question: will my business analysts be able to create robots on their own? “If the answer is yes, you can avoid waiting weeks for a custom coding effort.
“Overall, these RPA solutions are relatively easy to configure – requiring no IT involvement. If you have the skills to map what an employee does in a process, it is likely you can train a tech-savvy business analyst in only a few weeks to create a robot to do it for them — in a few hours and without coding skills.”
Do not forget Project Governance!
While we know that each task’s automation may be a small piece of work, it is still vitally important to treat this as a project with the appropriate level of governance applied. Therefore, you should not overlook Project management skills.
Consider the future!
If you are a large organisation with a company-wide automation initiative, you may look to establish an ‘RPA Centre of Excellence’. “We see this happening more and more as the benefits of RPA are recognised and adopted across an organisation,” says Sharma.
The reality of this is that we are likely to see more focused RPA roles. Examples include ‘RPA Developer’, ‘RPA Tester’ and the wonderfully named ‘Bot Orchestrator’ to name just a few. Of course, this team would also include Solutions Architects, Project Managers and Business Analysts.
So, there is nothing to fear from a skills point of view when considering an RPA project, if you choose the right vendor for the job and approach it in the right way!
This article is sponsored by Servicetrace – automating the world’s most complex enterprise processes.