June 16, 2020

RPA Developer and Business Analyst – do we need both?


Darko Jovišić

Very often in RPA team blueprints you will find two roles among others: RPA Developer and Business Analyst. In a nutshell, business analyst should talk to the business side and gather all the requirements and details about the process in question. Based on that he creates process definition document which he hands off to the developer who implements in the tool.

I would like to raise a question and challenge this separation of duties: do we actually need two roles?

RPA was invented as low-code or no-code approach technology and as such it should be easy enough for a technical-savvy business analyst to master it. If we need a role with „developer“ title then why do the vendors market it as business user friendly?

This separation of roles creates more problems then the benefits it brings. Automation of processes, based on our experience, is measured in weeks with 2.5 months being the longest implementation we ever had. So, we are talking about relatively short implementation cycles. By introducing two roles to the project we are introducing several risks:

Expectations vs. Reality – Developer does not understand the context and the nuances of the process because he/she most probably never saw the business stakeholders. There is a risk that final delivery will not be what the customer expected because business analyst maybe didn't collect enough technical details for the developer which in turn can create problems in production and loss of enthusiasm from the business side

Lower overall quality – Since developer is not talking to the customer then the business analyst is the one that determines how the automation will be designed. Because of that we are missing an opportunity to design things in a more robust and scalable manner from the technical perspective.

Prolonged implementation – Because of unnecessary hand-offs we are prolonging the implementation and opening a lot of space for misunderstandings.

I'm more in favour of an approach where we have one single role called Automation Consultant. He/she should be in charge of the entire automation process from the initial customer workshops to production release. I'm calling it intentionally Automation Consultant because I see it more wider than just RPA. Automation Consultant uses RPA as a primary tool but can also apply other automation techniques and tools in order to achieve optimal automation.

Now you may say that the person I described is impossible to find. I do agree that maybe it's somewhat harder a person who can talk to the business and IT and at the same time write scripts and database queries. But, it's not impossible, it requires more time spending on candidate search and on-boarding them.

But the result is worth it because the customer will have a single point of contact and RPA journey will be much smoother.
Thank you for leaving a message!
Other posts
  • Procedures


    Ena Martinek


    July 21, 2020

    Based on consulting experience, we have developed a feature called procedures to help you manage big projects without copying the same code in multiple...

  • Exception handling


    Ena Martinek


    June 18, 2020

    When the process is done manually, most of the time employees can recognize errors in the process but what about the robots? What will the robot do in those...