What should be considered before, during, and after opting for RPA based solution, and how that choice influences the user.
With all the possible digital and technological solutions out there it is hard to get your head around where you should be focusing your attention when you are designing a solution for your problem or even a set of problems. Probably a whole set of problems can be solved with some “simple” RPA solution rather than some fancy AI or machine learning as you initially thought.
What is Robotic Process Automation (RPA)?
It is using automation technologies for improving business processes in combination with other technologies and systems. Tiny “robots” complete back-end tasks, usually of repetitive and rather find and fetch nature, and eventually if required they deliver the information to a graphical interface. The benefit of using such a technology is because it surpasses significantly a human at efficiency while it can complete multiple tasks simultaneously in a very brief time. That said one may think that is exactly what I need but as we will entangle further in the article there are significant obstacles to consider before diving in completely.
But isn’t the RPA dead?
A valid question if you haven’t heard much of a buzz lately. It might have just gotten submerged by other more trending topics, but it never went away and probably it never will. In almost most medium to high complexity applications, there is an engine that makes things work. Or to be precise a lot of tiny engines that make the whole system run. Nowadays it almost became implicit that such a technology will be used. We are not going to enter into the merit of all the possible implementation of RPA and how it can flourish, but we are going to focus on how to identify a possible fertile ground for its implementation. Moreover on how that discovery considers a human as a part of the equation of a successful outcome.
Set up the grounds
The first step of setting an environment for RPA exploration is to learn about RPA and how it works which will help you identify faster in your process what are the points of interest. It is not expected that one knows A-Z all the IT systems and applications and how they work but make sure that you have access to the information of the IT structure, your data governance and, data management. And possibly include the people that are area experts in your exploration process. It is paramount to know your business process in depth. All its flaws, shortcuts, by and off-the-book actions. Lastly, consider technical and economical feasibility or better the amount you are willing to commit so you can direct your exploration and later the ideation of solution in a way it derogates the maximum of what is your technical and economical commitment.
- Learn about RPA
- Know your IT systems & Applications (IT structure, Data governance, and Data management)
- Know the business process in depth
- Consider technical and economical feasibility
The professionals to include in your process of exploration should include a technical expert on the RPA tool to-be-used (unless you are making a custom one), the business of the process to-be-automated, representative of the IT landscape within the organization, and a Delivery team (PM, Designers, Scrums etc).
Not all magic can be done with RPA
As it is important to know your IT landscape and business process it is equally important to know what not to expect of RPA. Recognizing the opportunities is great but it’s even more important to recognize pitfalls. RPA is not a technology that can be applied in isolation so consider that additional cost, time, and other technological solutions will be needed to provide the ultimate solution.
When RPA solutions are implemented they are not meant to completely exclude or reduce the human labor, on the contrary, it will still very much need their presence. Furthermore, not all business processes are RPA friendly. We will talk about this further down but it is ok not to use RPA in a process that in the aftermath would detract less value with RPA than without.
Not just any RPA tool makes the right solution, it’s faulty to assume that all the RPA tools have the same properties and can be applied equally to any business process. Don’t assume that it won’t have a significant impact on the organization and the process to-be and mostly that it won’t change the work balance of employees, so make sure that you address these things on time.
What kind of processes should be automated?
There are about 8 rules that define a process that has the potential to be automated. Yes, preferably you should checkbox all of them. Automate a process if:
- a process is based on strict rules that should be followed. Milestones or checkpoints to do
- is a process that contains repetition, repetitive tasks, or a process that itself is repetitive
- is a process that is fully manual or is made of a lot of manual tasks that can be repetitive as well.
- is a process that handles a high volume
- is a process (or parts of a process) that is determined by a frequency such as daily, weekly, monthly, seasonal or critical
- is a process that is triggered or supported by data. Such as automatic responses triggered by form compilation or similar
- has a low exception rate. Very important if not essential matter of automating a process. It has to have a relatively low number of tasks that have to handle exceptions. If there are too many exceptions to handle all together the success of RPA could be significantly lower because of the complexity of when-if scenarios. Note that it probably would take more time to implement it too.
- finally, is a process that has a high rework rate which is something that should be researched carefully.
All together when we are talking about the rules that define highly probable automation possibility in a process we have to conclude that are a few “musts”.
A process must be clean and lean, as well as standardized and stable. The validation has to be possible and the data is or can be structured.
Designer’s checklist for an RPA exploration and implantation
As usual, map the process as-is in depth. It is essential to understand all the rules, tasks, and barriers. This also applies to data and other systems involved. Design a process to-be-automated with the emphasis on the key rules (“make or break points”) in it and the human-machine touchpoints. This part is important because of the feedback loop necessary for validation and double-checking of the automation. This brings us to the definement of the controlling mechanisms (decision making and approvals) guided by the good old 4 eye principle. Design for double-checking: human checks the machines and the machines checks the human.
Design for double-checking: human checks the machines and the machines checks the human.
Map the exceptions carefully because the process with the least exceptions should be considered for automation. Most importantly fixing any bad process before automating is fundamental. Do not, absolutely do not, try to automate a process that has flaws and complications that should be resolved beforehand. Especially if they include business logic and workflow. Mounting an RPA on top of all that will make a bad process even worse. For RPA to function optimally it needs processes that are clean, regularized, and standardized as much as possible.
Most importantly fixing any bad process before automating it is fundamental. Do not, absolutely do not, try to automate a process that has flaws and complications that should be resolved beforehand.
Defining the automation goals is equally important. This will keep on track the whole team on what is planned to be achieved. Any additions or deviations should be evaluated considering the main goal of the automation. In other words what problems are we here to solve?
When designing and defining tasks in the new experience to-be, think of how that design would perform if it would need to scale up in the future. This cross-check could be done with the rest of the team as well. If we think of scalability early on we are building a more long-lasting and sustainable solution for tomorrow. That’s why is good to test the concept for scalability.
Although we are designing the user’s experience, which most likely will be somewhat defined by the data flows (the in’s and out’s), you will find yourself mapping the data flows on the surface, and where they cross roads with the user experience.
Now, apart from the usual happy flow, there is a job to map and design the journeys of the exceptions. What happens if “B way” is taken instead of “A way”? This is something natural to the design process but it’s particularly important for RPA solutions. This way you are preserving a good user experience throughout, even when it goes off the road, which happens more often than one might think.
What happens if “B way” is taken instead of “A way”? …particularly important for RPA solutions. This way you are preserving a good user experience throughout, even when it goes off the road…
Lastly, the designer should be informed or even better be part of the definement of the level of automation of the solution. The automation could be assisted (dynamic, cognitive) or unattended (foundation automation). The designer here can provide the team with a useful insight of when and where the automation would be more suitable or preferable. It works the other way around as well. The designer should be informed of the level of automation if it crosses paths with the user’s experience. Remember, a good user experience consequently makes better working and less error-prone software.
Allocating the responsibilities: Human-computer interactions
As giving the best possible user experience is primary for a designer, therefore, knowing the limitations of an RPA robot will help not to overshoot. But, now a new question arises how will you know who is better at performing a certain task? Well, there is a golden rule: Allocate the responsibility of performing a task to whoever is the most capable of doing the task. So let’s see who is good at what?
Humans are really good at:
- Diffuse pattern recognition
- Situation awareness
- Approvative & tolerable workloads
- Monitoring & error prevention
The “machines” are pretty good at:
- Complex algorithmic calculations
- Close-ended deterministic calculation (Permanent automation)
- Anywhere there is a decreased degradation of human skills
Conclusion
Overall the solution technically should strive to be modular because there will always be a need to shift pieces around (flexible and extensible). It should be easy to maintain so it can become a reliable system. Readable because it needs to integrate with other technologies well (the easier the better).
On the other hand, from the user experience point of view, whatever the solution is going to be it has to aim towards establishing and maintaining the user’s sense of self-worth. Moreover, it needs to establish trust in automation for the users and the clients. Therefore everyone can perform their tasks confidently while relying on each other. The ultimate human-machine trust loop. Even more importantly it has to be open to conversation. It has to be easy to give feedback when something goes wrong or it needs to be redirected.
Especially important for the user experience and integrity of the process is that it has to be easy for the user (a non-expert) to correct or prevent most of the errors without particular specialist intervention.
