Robotic Process Automation – What I have learned so far

Process automation, or sometimes Robotics Process Automation – RPA (we can discuss the differences of the two another time) is becoming increasingly popular. And for a good reason. It can save your company a lot of resources, often by doing some quite simple stuff. However, simple doesn’t always mean easy. And when it comes to process automation, I have made my share of mistakes and learned quite a few lessons in my five years of working in the field. Here is a couple of the things that I have learned so far…

Know your process

Imagine building a robot for baking a cake. Without knowing the exact recipe, as well as how to execute it, I think we can agree that you are on the path to failure. Automating a business process is the same. I have been involved in more than one project, where we tried to use automation to fix a broken process. It doesn’t work that way. You must fix the process before you automate it.

Automation & orchestration

In the context of automation and orchestration, I define automation as filling out fields, clicking buttons etc. Using something like Blue Prism or Selenium to fill out a form on a website is quite simple. But often, this is just a one step (out of many) of the process. The difficult part often lies in how to orchestrate all the steps. What if a certain type of task needs to skip a step. What happens if a payment doesn’t match the expected amount. What if some sales person promised a certain customer, that they get a different due date and fee, than everyone else (this one is quite common). Taking everything into account, and orchestrating all the automation steps, is way more challenging than the steps themselves. Luckily, if you succeeded with my first point (knowing the process), this will become a lot easier.

Supervised or unsupervised

You can divide Robotics Process Automation into two categories: Supervised and unsupervised. I might write a more detailed post on this, but for know, here is a simple definition of the two:

• Supervised RPA is when the automation is initiated and supervised by a human user, typically using the authorizations and access rights of that user.
• Unsupervised RRA is when the automation takes places on a different computer with a different user and hence different authorizations and access rights.

It matters which type you chose for your process automation. With the above definition it should be clear that unsupervised automation can struggle in environments which are heavily gated by strict authorization policies. Something which is especially common in enterprise organizations.

Both of these types has their pros and cons. And there is no single right choice, it depends on your project. But make sure to consider carefully, which one you use.

Principles and best practices

Maybe you just bought your first Blue Prism license and are thinking: “Sweet, a no-code tool. Finally we can stop spending time on all this software engineering nonsense!”. Sorry to spoil your party, but no, you cannot. The principles and best practices of software engineering very much applies to no-code (drag and drop programming) as well. Maybe not always 1:1, but it’s pretty close. A modular design is still a good idea. The Single Responsibility Principle also applies to no-code. You didn’t change area of expertise, you just changed the tool.

You might think that maintenance doesn’t matter. After all, RPA is just a temporary solution. While that is true, temporary often lasts longer than people expect. Don’t be surprised if your RPA solution ends up lasting several years. And when that is the case, you need to be able to maintain it.

Conclusion

These are just some of the thing that I have learned, in the five years I have worked with process automation. I could probably have added a few more, but then you wouldn’t have had time to read the entire post. If I am to summarize all of the above, it would probably be, to treat process automation as actual software development – because it is. It might be unique in certain ways, but so are many other branches of software development. However, do it right, and it will save you a lot of money.