RPA developer and business analyst – do we need both?
Generally, in RPA team blueprints, you will find these two roles among others: RPA Developer and Business Analyst. In a nutshell, a business analyst should handle the business side and gather all the requirements and details about the process in question. After that, he/she creates a process definition document, hands it off to the developer, who implements it in the tool.
However, do we really need both?
The main idea behind the RPA technology is that it’s supposed to be a low-code or no-code approach technology. As such, it should be easy enough for a technical-savvy business analyst to master it. If we need a “developer” role involved, then why do the vendors market it as business user-friendly?
This separation of roles creates more problems than it brings benefits. Implementing the process automation, in our experience, is measured in weeks – the longest implementation we ever had was 2.5 months. So, we are talking about relatively short implementation cycles. By introducing two roles to the project, we are introducing several risks:
Expectations vs. Reality:
The developer doesn’t understand the context and the nuances of the process simply because he/she probably never saw the business stakeholders.
There is a risk that the final delivery will not be as the customer expected it to be. If the business analyst didn’t collect enough technical details for the developer, it could create problems in production and loss of enthusiasm from the business side.
Lower overall quality:
The business analyst’s job is to talk to the customers and determine how to design the automation, while the developers are often excluded from the brief. That way, we’re missing an opportunity to develop a more robust and scalable process for a client.
Because of unnecessary hand-offs, we are prolonging the implementation and opening a lot of space for misunderstandings.
In my opinion, we should have one single role -an Automation Consultant. He/she should be in charge of the entire process automation, from the initial customer workshops to production releases. I’m intentionally calling it Automation Consultant, as there’s a bigger picture than just an RPA. Automation Consultant uses RPA as a primary tool, but they can also apply other automation techniques and tools to achieve optimal automation.
Now, you might say that the person I described is impossible to find. From my experience, it’s challenging – but possible. That person should be able to talk both to the business sector and IT and write scripts and database queries. It might take time to find and onboard the candidate, but in the end, it’s worth it. After all, the customer will have a single point of contact, and the RPA journey will be much smoother.