To err is human but can be robot too
RPA has been on everyone’s radar lately and most of the financial institutions have already pulled the trigger on the digitalization of lots of their processes. All studies will put forward the advantages of a plug and play robot that will replicate human actions, how it makes the process safer, how it allows to increase the volumes and how it helps to reduce the costs.
At DynaFin, we have been involved in several RPA projects for some time now and if a client comes and asks **‘should we jump on the robot bandwagon?’ **our answer is very simple: yes! Without any doubt… but…
That ‘but’ is precisely what I want to discuss in more details.
Why? Well as I said, the benefits of a robot are more than documented but — and here comes the but again —** you’ll read very little the pitfalls that can occur**.
Yes, a robot can be plugged and can provide a huge return. No question here.
But it remains a change and like any change, if not handled properly, it can rapidly backfire. How many times haven’t we seen a new technology frustrating the users more than helping them? Was it because of the technology itself? Not necessarily. Most of the time it was more due to a poor strategy surrounding it.
Still with me? Good, so let’s dive in the core of this article: what are those so-called pitfalls and how can we avoid them ?
1. First thing first, think globally:
You will tell me: this one seems like a no brainer and I am playing safe. Well, from our experience, not so much to be frank. We joined lots of RPA projects when a few robots were already implemented and things turned sour because the expansion was difficult to handle.
Many of our clients decided to test that technology by robotizing a few processes here and there just to see if it helps. When they realized it worked, they decided to automate a few more but still without a clear plan on the longer term. Very quickly, they ended up with a chaotic list of tasks performed by robots without having a real overview.
In a first phase, those robots will surely help but at some point, a sporadic spreading will start generating conflicts. Implementing a new robot will negatively impact another or will make another one useless.
Such as in other projects, chaotic developments will lead to problems, but it is especially true for robots.
So OK, start with a Proof of Concept. But before rushing into RPA, it is important to have a transversal vision that will allow to connect the dots and maximize the potential of the robots: define the benefits you want to get from the technology, list your main processes and prioritize them according to these benefits, think about the future governance,…
2. A sound process is an optimized process:
Once the roadmap is clear, it is time to clean up the process before it is automated.
As for the previous point, it sounds like common sense, but you will not imagine the amount of times we run against robotized processes that look more like a Frankenstein’s monster and that deliver only part of the expected benefits at best simply because they were not optimal to begin with.
Always keep in mind that robotizing a complex process limits the return once implemented and will also pass on the complexity in the coding; making it more difficult to maintain and more subject to failure. (Not to mention the frustration it will generate within the users and the negative impact on their adoption of this new technology).
We cannot repeat it enough: please optimize the process before it is automated!
The silver lining in this story? Optimizing a process is what we at DynaFin do best!
3. ‘Think robot’ should be the new motto:
Devil is in the details, especially in a project environment. Now that robots are a part of our daily life, we must gain the reflex to systematically assess the impact of any project on the existing automated process.
We recently faced a case where another project — having nothing to do with RPA — had changed the layout of a report that was actually used by a robot later in the chain. As a result, the robot was no longer able to find the right information and thus stopped doing its work. RPA is not AI and the smallest change can break the whole automation.
With the increased number of robots, this is an issue we see more and more: too many projects are still delivered in silo without considering the impact on robots from other teams or departments.
It seems logical to identify the impact of a project on the end user so why not having the same reflex for a robot? After all, they are replicating the tasks of the users.
‘Does my project impact any RPA process?’ should be added to every project checklist!
4. Build a solid center of excellence:
Once automated, the project is closed, the project team celebrates the implementation with a drink and hands the keys of the house to a team in charge of the maintenance.
Putting together such a center, team, call it the way you want it, is the right thing to do and a must-have in any robotic world. But most of the time we see that these centers are not sufficiently equipped, staffed or trained.
Remember the previous point? Someone changed a report used by a robot and it can no longer run. Who are you going to call should you face such a case? The center of excellence. They will fix the issue and the robot will work again. Happy days.
Today’s reality is a bit different. Because more and more tasks are automated, what we actually observe is that the number of problems is piling up as more robots are going live. The center is no longer able to absorb the volume of issues and your broken robot falls in a line of other processes to fix. As a result, the robot is down for a few days.
In the best cases, the tasks are manually handled by the team who used to execute them before their automation.
But in most cases, the automation has reduced the number of staff and the team is no longer able to absorb the processing of those tasks.
And in the worst cases, the persons who used to perform the task is even no longer in the company!
This is — for obvious reasons — a pitfall you really want to avoid. Trust me.
5. Last but not least, another item often overlooked is the post-implementation follow-up.
It is not rare to see a project considered closed once the robot has been moved to a production environment. No one is analyzing if the robot is actually delivering what was expected in the study. Do we save the time expected? Is my process really less risky because it is performed by a robot? These are some of the questions that should be asked but are often skipped.
Also, very few lessons are learned from RPA implementation. When you think that robots are often modeled based on existing ones, a small mistake not handled can have a ripple effect on upcoming RPA projects.
So yes, Robotics is definitely answering to a lot of challenges in the financial industry, but if you don’t want to hear people in you organization saying that it doesn’t work, take some time to think about it through before starting your project.
At DynaFin, we take pride in helping our clients navigating through the rough waters of the robotic process automation, thanks to a specific approach based on our experience in implementing robots.
This journey can be full of obstacles but — and I’ll finish this article by a positive ‘but’ this time — if you take into consideration the points I have listed above, you should avoid many unnecessary obstacles that hinders the benefits of robots.