The RPA Rewind
Its RPA, Stop thinking like a Human
It truly is an amazing time for RPA, software based robots doing amazing things. For smart Architects and especially those that do think outside the box having this type of power is truly amazing. RPA allows for smart people to now be great decision makers while those robots perform the same repeatable tasks over and over again.
So if this is the road in which we are traveling then why are we at times still designing robots to think like humans? RPA robots are not human they do not possess eyes nor have they any Cognitive ability at least not yet. So from a design approach our workflows need to reflect these limitations and if done correctly the robotic processes that we architect can do just as well if not better then those of our human counterparts.
So how do we do this? There are two important factors that architects need to consider and those are risk assessment and ensuring that robotic solutions are broken up into logical units of work that make sense.
Risk: Its important for Architects to always be assessing the risk that a robotic process automation has on the overall business outcome if the RPA workflow does not complete successfully. Its prudent to always consider the edge cases and configure the robots to either address the edge case or exception gracefully so that the issue can be easily triaged and fixed by a human if necessary.
Logical Units of Work: Logical units of work can best be described as the decoupling of an entire process into logical units whose tasks can easily be accomplished by a robot with little to no occurrence of error or exception.
RPA workflows need to use technologies available to the enterprise that will lesson the overall risk to the business outcome while at the same time ensuring that the overall goal of the logical units of work are completed consistently as desired.
Lets illustrate this using an example. Lets assume that your organization has an ERP system where transactions are entered into a starting queue or folder, from their additional human work is required on those transactions. A human must log into the ERP and navigate to the queue or folder, using their eyes and cognitive ability the human must then select a transaction from the list and start to work on it.
Using a human this process seems pretty straight forward, however replacing the human with an RPA robot one can see areas of risk and exceptions and probable gaps within the unit of work.
Stop thinking like a human, and more like a Robot
Lets begin by removing the sight and cognitive ability from our process. The first question that should come to mind is how is a robot supposed to know which transaction in the ERP to work on? We should also keep in mind that humans do not work in continuous looping fashion so as architects we should also design our processes to be more reactive and synchronous so that the robots are not continuously looping if possible. Remember continuously looping robots result in large un-meaningful log files.
The answer is to make the initial transaction smarter. You do this by
- Attaching a workflow or a trigger to the initial transaction so that when the transaction is posted to the ERP this event will send a request to the RPA work Queue passing the Transaction ID as a piece of metadata.
- That single action will then invoke a robot who will log into the ERP.
- Perform a simple search based on the Transaction ID.
- From the search results a single transaction record will be returned.
- Now the robot has a single item in which it can work on. Of course extra configuration should be added to deal with the event that no record comes back from the initial transaction search however this should be an edge case but good stewardship should have this covered.
So there you have it a process that was always human powered, now with a little re-factoring, the removal of sight and cognitive ability we now have an RPA process that has less risk then it would if we were to keep the robot acting like a human.
About the Author
Troy DesBarres is a Founding Partner and Automation Architect at MagicLamp Software. Troy has been a thought leader in IT for over 15 years. He has a practical understanding of the operational challenges that face businesses, and he brings a wealth of experience architecting solutions to meet those challenges. Troy’s leadership has helped position MagicLamp as a leading software solutions provider. To learn more visit the following: MagicLamp Software, Datacap and RPA.