Since the dawn of the computer age (and before!), technology has been used to automate business workflows, be it order entry, inventory management, credit application processing, etc. At first glance, RPA or Robotic Process Automation, seems like another term for Business Process Automation (BPA). What distinguishes RPA from BPA, is that a programmatic robot – or bot - is replacing human interaction with a user interface, such as a form in a browser.
Let’s face it, even in the digital age, there are still times when the programmatic interchange of data between systems is not practical and/or possible. Traditionally, we would have hired clerks to perform data entry tasks, or asked analysts or other team members to perform these duties. IT might get involved and spend thousands of dollars creating APIs to allow access to the systems. At its most basic level, a bot can be created and deployed to perform this action.
And in certain cases when IT cannot or will not create the bot, business team members have taken it upon themselves to create and deploy the bot themselves. Like the wizardry that used to be performed in Microsoft Access or by using Excel Macros, these bot creators are now automating data entry tasks and removing the human element that was present in the workflow automations of the past.
Citizen Data Scientists have been getting a lot of buzz over the past couple of years, as access to data has been democratized and IT departments have enabled self-serve data analytics. On a similar note, it appears that a new group is emerging in the workplace, Citizen Robot Builders. These are typically business team members (generally not IT or traditional developers) that have a penchant for programming and a desire to automate some of the more mundane tasks that their business unit performs. The proliferation and accessibility of Python has certainly contributed to this, as well as browser automation frameworks such as Selenium WebDriver and Puppeteer.
Bot based automation is no different than any other process automation, at a certain point, IT will want and need to exert some control over the bot creation and management process. Questions that will likely be raised are:
- Who is responsible for the maintenance of the bots if the underlying systems change? For example, if the bot is entering data into a web-based form, what happens when the form layout changes? Assuming there is a login required to this form, what happens when the login credentials expire? Who will notice? How?
- Where is the source code for the bot? On a business analyst’s laptop? Are there variants of the bot that have been created for similar but slightly different purposes?
- Are their security or compliance issues with how the bot is accessing or updating data? Are their HIPAA, ePHI or GDPR concerns that must be mitigated (or at least acknowledged)?
- How are the bots deployed? Where are they running? What if multiple bots need to perform a task in a certain sequence, how is that orchestrated?
The larger your organization and the more bots you have deployed, the more important and critical the answers to the above questions become. The thought of dozens (or hundreds!) of bots running rampant throughout the organization, with no centralized control and monitoring mechanism in place, is somewhat concerning. In an ideal situation, RPA would be a stop-gap toward a more controlled API driven solution that would likely be easier to maintain and monitor. But, as with most decisions, the ROI must be justified.