John Booth, Senior Director Business Process Management, Fresenius Medical Care
When we introduce the concept of RPA to our business operations teams at the start of a project, there is usually a palpable sense of excitement as the participants think about all the tasks they currently do that will be automated. However, at three key stages of an automation project, our typical experience is that this level of energy significantly dips as reality kicks in. Understanding when to expect these challenges, and why they happen, can help prepare the project team to address them and ensure project success.
The first key challenge comes when the business operations teams submit their initial list of candidate processes for automation. Despite best efforts to explain the characteristics of a process that is suitable for automation using RPA, this list usually contains a significant number of processes that are not suitable. A key driver for this is that business operations teams are often focused on trying to resolve what they see as their key issues, or pain points, rather than focusing on what processes are most suitable for automation. The realization that RPA will not resolve these pain points can lead to frustration and despondency. However, this presents an opportunity to re-engage and re-present the key messages with regards to identifying suitable processes for automation with RPA.
A key driver for this is that business operations teams are often focused on trying to resolve what they see as their key issues, or pain points, rather than focusing on what processes are most suitable for automation
Once the participants are refocused on identifying suitable processes, the enthusiasm will soon return as they focus on a positive outcome.
The second key challenge comes during deep process dives, where process walkthrough and initial documentation activities take place. Often during these sessions processes that were identified as suitable are often shown to have key issues related to automating them, for example, additional data input is required, judgments may be required, decision paths may be much more complex than originally thought, required data is in unstructured formats or data is received in multiple formats. Again, this can cause frustration as what might be relatively straightforward for a user to handle becomes much more complex when the process is automated. However, all may not be lost; it is important at this stage to revisit the current process to see what can be simplified, adjusted, or re-engineered. While this creates additional work and may lengthen the time to complete the automation, it is far better to automate a good process than a poor one, this will reduce the number of automation errors on go-live.
The third key challenge arises once the initial automation is complete and undergoes testing, or during stabilization when there are a number of errors or automation failures. This can be particularly frustrating as users, and the project team may blame each other for missing key information or not mapping the process properly. However, this is just part of the deployment process. Exceptions are always likely to exist, even in the best processes, assessment is required as to their relative volume and based on this, it may not be advantageous to create automation to cover every exception scenario, but provide a pathway to a user to complete.
In summary, while RPA can certainly bring tangible benefits to businesses it is key to be aware that applying RPA is not a case of waving a magic wand to fix user problems; it is only one tool in the process improvement toolkit. Knowing what challenges are likely to arise during automation projects will better equip your teams to deal effectively with this and ensure better project outcomes.