Today we are going to talk about Robotic Process Automation. I thought it might interest our followers to review what it means, where it has come from and the problems that it both addresses and may introduce.
As we identify what Robotic Process Automation is, it might be useful to see the options that an enterprise has for how it automates more of its processes. More automation will generally provide more predictable, scalable processes.
1) Core Systems Increasing Span Of Control
General Ledger -> Payables -> Expense Management
SCM -> Warehouse Management -> Distribution Requirements Management
CRM -> Sales Force Automation -> Meeting Scheduling
Advantages
Same look and feel
Vendor responsible for coordination
Disadvantages
Generalist Applications
2) Non Core Systems getting coordinated through a Bus
Warehouse Management : Traffic Management : MRP -> Distribution Requirements Management
Advantages
Ecosysstem of Best of Bread
Disadvantages
Coordination of integration
3) Office Automation Tools connecting elements of a process
Forms -> Spreadsheets -> Incident Management
Document -> Folders -> Email Approval -> Timesheet Entry
Advantages
Leave users in the tools they are used to
Disadvantages
Processes can extend in an organic manner with no oversight
Some parts of Robotic Process Automation come from the Workflow Management world, A business process that may touch many systems and have many human tasks. Oracle provided a common workflow management tool used by many applications. However, it had difficulty finding its audience. The user interface was generally too technical for business users, and too long winded for programmers. Programmers prefer to code. The strength of Oracle Workflow was in coordinating human activities.
Some parts of Robotic Process Automation come from the integration management world. A business process that may touch many systems needs to have access to programming interfaces to those systems. An evolution of the Oracle workflow management tools happened when Business Process Execution Language was in vogue. At that point, the Oracle BPEL Engine took over from Workflow. It moved closer to the technical audience. The strength of the BPEL Engine was in integrating other systems.
Some parts of Robotic Process Automation come from the UI Flow. This has a long heritage. My first programs written in the workplace were done in Lotus macros. This made feasible a process for which you might have been able to use a keyboard for a single transaction, but if the process would require a thousand such transactions it would not be feasible. In a more modern era, capturing and replaying keystrokes has enabled us to test software at scale. It also gives a way to integrate a business flow that crosses many systems and still use the logic and validation inherent in those systems. This allows the automation and integration of systems where programming interfaces may be missing.
When office automation tools have reach the limit of what they can do, with the connections between them being human activity, RPA may relieve that pressure and increase the utility and viability of solutions that have emerged from within a department. For example, working at a University, there are many sources of funding that may have their own time tracking and audit requirements. There tends to be no forum in which a common approach and unified system can be agreed. Therefore time tracking tends to happen in multiple systems with multiple "Source" documents. A department within each funding source may well have designed the form on which time must be recorded and approved. Keeping track of source documents and approvals within these constraints can be overwhelming for human administrators. Without governance structures to agree a common specification, mutiple source documents may need to be filed and routed for approval. RPA provides a strategy to coordinate. It exposes human beings to least complexity while serving multiple masters.
It means stakeholders at departmental level can retain the pieces of a solution that they may have created while the fabric of a broader solution is woven in the RPA Tools.
Least disruption to the status quo means that the change management is easier and resistance to change is minimized.
In general, there are much lower learning thresholds for the RPA Tools, meaning that you can find RPA solutions have been built by experts in a department without the disciplines that you would need to develop commercial software. In a commercial software company, managers tend to be aware of the technical debt and have Software Development LifeCycle processes to measure and trap it.
It provides an easy path for customization and filling in gaps that maybe should be filled by the incumbant applications. Packaged software may contain features beyond those that you used when you deployed.
You always have to remember that the cost of maintenance of the solution is the killer. Not the cost of development.
The shorter-term fix may delay evaluation of the larger solution
RPA solutions may start to rely on talented individuals and tribal knowledge without thinking how to ensure that processes can survive changes in personel. This is no different than for manual processes. It takes discipline to keep processes documented. It takes design expertise to make them obvious and self-documenting.
SSTC will look at a process deficiency and see how it can best be remedied. This might be using RPA tools. It might be using the packaged software in different ways. It may be an application governance problem. It may be purely a procedural issue. The fact that we are not looking through a single lens that presupposes a solution, means that you can have confidence that you have the correct solution to your process automation problems.