Last Summer, I was assigned to a Robotic Process Automation (RPA) project as the Lead Developer. RPA is a growing field because the automation can improve work throughput at a greater accuracy.
We recently completed the development and introduced our automated process. A process that once require tens of hours was completed in minutes. While it was very gratifying to deliver this product, I look forward to returning to test engineering soon. As I take leave of this RPA world, I thought about the development experience and wanted to share some thoughts.
From Test Engineer to RPA Developer?
I was looking for a different gig within my company. One platform was experimenting with RPA and thought a Test Engineer (that is, a person with automation experience) would be the best fit. When I investigated the job a little more, there was some chance that I could explore AI. I was offered the position and started learning about RPA and an RPA tool.
Emperor’s New Clothes
RPA is marketed as tools that can save labor, improve accuracy, and increase productivity at a lower cost all through automation. In my opinion, all of that is true. I also believe that RPA tools are marketed more towards the business side of an enterprise. The sirenic user interface of an RPA tool may have you believe that anyone can create process automation. The reality is that these tools are used to write programs, and writing programs – even RPA programs – is challenging.
The RPA tool is actually just another Integrated Development Environment (IDE). Make no mistake – it is used to create scripts that interact with your applications in the same way as your employees. In that sense, the creation of a script is very much a software development effort and must be treated as such. There are no robots here and the use of the word “robot” is very misleading and should be considered window dressing.
If you believe that someone with Excel macro experience can use RPA tools to deliver high quality, error free automation, you will be, in many cases, profoundly disappointed. Excel macros and RPA programs are on opposite ends of a development complexity spectrum. Without an understanding of software development methodologies, basic programming concepts, data quality, or detailed process definitions, it is possible to realize significantly less benefit than expected. In my opinion, the “best practices” recommended by RPA tool companies are a sad substitute for software development experience.
Early in the project, I found many similarities between what I could do in Visual Studio (also an IDE) in C# and the RPA tool. With my experience in software development, I was able to learn the RPA tool quickly. The RPA user interface is but an abstraction of basic programming concepts, and it reminded me of the Lego Mindstorms IDE used by many children to build and program small mechanical machines (these machines can perform some sophisticated activities as demonstrated annually by many First Lego League teams).
In my opinion, placed into the hands of a professional developer (or developers), the RPA tools can deliver great products that can benefit your enterprise. However, that benefit can be realized only with a strong working partnership between the development team and your business team.
Tests and Testing Tell the Story
The first process we automated was complex. It was as complex as a new API and warranted the normal approach of decomposing it into components. The components were described in multiple story cards and we started construction.
At the end of a story card, we found it valuable to create unit tests for the components. Even the tests were built in the RPA tool. In this manner, we could evaluate multiple scenarios easily. When we had a critical mass of components, the development team met in what we called an “Integration Session” to assemble the components into the automated process.
We evaluated the automated process with sample input data, and we were able to provide diverse scenarios that exercised the process. We found defects and corrected them. We were also able to demonstrate the automated process to our business team members frequently.
Discoveries Along the Way
The description of our development approach should sound familiar to agile practitioners. Agile provided us the flexibility we needed to learn and adapt.
For example, we wrote code to collect a set information for a person from an application. We discovered that, sometimes, there is more than one person. We refactored to collect a set of information per person.
We wrote code to place numbers into a spreadsheet and retrieve formula results. We discovered that, sometimes, the spreadsheet provides feedback and the formulas require a macro to make adjustments. We refactored to detect the feedback and run the macro.
We continued in this way until we deployed the process and started using production data. While we still made discoveries and refactored, we also realized that the cost of some changes may not have enough benefit to justify the change. We discovered “done” and, as hard as it was, we needed to say “enough”. That doesn’t mean our discoveries are not addressed rather it means the project met its goals. The discoveries and enhancements will be addressed over time.
Right Size Your Team to the Process
When considering processes for RPA, the complexity and effort should help set the level of project management.
Our team is a handful of developers and business consultants. To resolve details for our first process, we required information from our business consultants frequently. Additionally, we relied on a separate team for test data. Since RPA is a software development effort and the process complexity was high, I appreciated the benefits our project manager brought to our project.
However, the second process was far simpler. In my opinion, it was simple enough that a two developers could complete it without the need for project management.
Celebrate The Team
Over the course of my project, the developers and I worked with some wonderfully gifted and passionate business people. They knew their business processes, they knew some of the challenges, and they believed in the promise of process automation to improve their productivity. Together, we defined, built, tested, and celebrated the products we created.