When we talk about the prerequisites for success for an RPA project, we often look at technical aspects of the job, such as in our article on Cognitive Automation.
There is another, equally important aspect that is not mentioned as often: the human element.
More specifically, change management.
This can be defined as:
an employee-focused approach that is utilized to aid the transition from a current state to a desired future state.
The transition to the future state, in this scenario, represents the implementation of the robot. But why is it so important that employees accept change, if it is the robot doing the work?
- The employees most affected by the robot are often the very same ones who possess all the necessary knowledge to analyse the process completely & efficiently
- They are often involved in preparing the necessary input files to feed the robot
- They play a crucial role in post-launch maintenance & support
- If they don’t accept it, they will likely be unhappy with the new state, influencing morale and their own performance on other tasks
There is a stereotypical, and somewhat untrue answer to why these employees would be unhappy:
the robot is taking over their jobs!
In practice, this seldom rings true. Unhappiness often relates to a feeling of loss of control. An example:
Barry has worked in the same department for 8 years. He likes his work and colleagues and is a true Subject Matter Expert. Suddenly he is informed he will have to explain ‘his’ process to an external consultant, who will be automating the process. This creates anxiety and insecurity: is it cost-cutting? Is his job on the line? Are his colleagues’ job on the line? What is all this automation?
If Barry has not received sufficient explanation and has not gotten the opportunity to talk and ask about the robotic workforce, this new way of working can be a concern. Frustration will build and he will stop co-operating or outright sabotage the project.
However, the more he learns about what the robot can mean to his team and their workload, the more excited he is to continue working with it. This is because the robotic workforce isn’t replacing workers, but is relieving them of their repetitive, mind-numbing tasks.
That, is exactly why change management is so crucial.
So how can we implement it on RPA projects?
- Explain your why
It should be clear to Barry and his department why this is happening, and what the scope is. Communicate clearly about the intended goal of this automation, and highlight the benefits: solving chronic understaffing, removing repetitive work, reducing errors. If time is being freed up, showcase examples of how it can be used: training, other types of work or projects.
Part of this can come from the consultant, but management is key in communicating this information. They are the leaders and hearing it from them is critical.
Equally, it should be clear what is expected of them: do they have to validate design documents? Prepare test cases? Communicate early and often about these subjects.
- Involve them
Barry knows what he’s doing. He’s handled every exceptional case you can think of. Asking for his opinion and input is the best thing you can do if you wish to create a functioning robot. It also creates ownership for Barry. The robot could not work without his contribution, and this should be emphasized.
Depending on Barry’s own goals, you could make him Process Owner, which would make him the reference point for developers and business alike for anything related to that process.
- Make it fun
Give the robot a name. Baptise him, if that’s your thing. That’s what we do!
If you follow these tips, we guarantee your project will be better off for it. And you get to show off your creativity with robot names! (But don’t call them T-800…)
Do you agree with these tips? Do you have others? Let us know!
Want to see how we did it? Check out Hugo!
Written by Nico Esposito for BrightKnight