The Real Benefit of an Easy to Use RPA Tool: An Opinion by UiPath's Chief of Strategy

RPA was initially invented to respond to the frustration of business people in large organizations with what they perceived, rightly or wrongly, as the inertia of their IT colleagues toward pressing business driven demands.

Vargha Moayed, Chief Strategy Officer UiPath

To implement RPA, one needs to intimately understand a process at its lowest level (i.e., working instructions) and all its exceptions, the actual word used for it being “user story”. In order to build an effective RPA script, it is important to have skills that allow one to understand, decrypt a business process and ultimately know how to harmonize and optimize it. Often, these skills reside with the process re-engineering talent such as, for instance, Lean/Six Sigma practitioners.

Consequently, companies that are trying to automate processes have two choices. The first approach consists of having business analysts that understand processes to build user stories and hand them over to RPA developers. The second approach relies on business analysts or Lean practitioners becoming RPA developers themselves, thus merging the two roles into one.

Currently, in the early days of RPA deployments, many companies prefer the first approach, whereby they have business analysts and RPA developers working side by side. This scenario is preferable to them because many RPA tools, despite their simplicity promise, are not so simple to use, hence need to still involve people from an IT background on the development side. What’s more, some companies believe that moving development teams offshore can lower the cost of automation.

By choosing this approach, companies tend to repeat the same mistake that has plagued IT development since the beginning, namely the difficulty in communicating and exchanging specifications between functional experts and developers compounded by offshoring. This has been already solved many times in the traditional IT manner, through the “waterfall” method. But it can be frustrating, error-prone and often not the best approach for RPA development that relies a lot on an Agile approach that calls for frequent interactions between process owners or end users and developers.

Conversely, the approach that consists of turning process experts into RPA developers allows for a higher quality script, faster and better understanding of exceptions, an opportunity for process optimization and, as a result, more rapid deployment. Obviously, this can only be achieved if the RPA tools development environment is intuitive enough for non-IT people to be able to use it such, as the one offered by UiPath. 

The simplicity of development is crucial when choosing an RPA platform. Naturally, process specialists turned developers will need the help and supervision of a solution architect with a broader IT knowledge. This approach delivers excellent results, and process specialists are excited to start developing, whereas conversely hardcore developers don’t find RPA development “sexy” enough and might be bored quickly, leading to high turnover.

Furthermore, for companies that still want to go with the first approach of separating business analysis from RPA development, simplicity allows them to tap into a pool of less experienced and less costly developers. Still, a higher turnover is likely to occur as the most talented programmers will migrate towards more complex development environments once they become better skilled.

And last but not least, a simpler, more easy to use RPA tool allows, of course, for faster development and, as a consequence, faster results.