Does Robotic Process Automation Need Rules-Based Processes?

It's not uncommon to see articles about robotic process automation (RPA) wringing hands about too much hype surrounding the technology. Often, the criticism is fair. However, the reader is generally able to throw his own grain of salt on overheated hype. It would be more helpful for RPA leadership to draw attention to a tendency that is harder to for the reader to perceive and correct – the careless and often (though unintentional) misleading use of terms.  For example, who wouldn’t want a dollar for every article or infograph saying this technology requires rules-based process? Yet, the reality is that is doesn’t. Not at all. In fact, if robotic process automation required rules-based processes, it would have died on the vine years ago.

 Asserting RPA needs rules-based processes is not only incorrect, it is damaging to the industry because the claim miscategorizes preconditions for success and makes adoption more difficult.

Business process automation is all about getting work done more quickly, less expensively and more acccurately. For companies to plan a successful robotic process automation implementation, they need to view decision and implementation correctly – not in the oversimplied context of processes, but in the larger context of work decomposition.

How Work Gets Done

Work in the business world consists of three core, interrelated elements: processes, activities, and tasks. These elements form a simple hirearchy whose ultimate structure is determined by the complexity and scope of the work itself.

Processes: A process is comprised of activities that must be undertaken and completed in order to meet a specific business objective.  Processes are generally documented – at least to the extent required for training – and impose policies, procedures and standards on all related levels of work.  For example, the accounting department of every company has a process by which the books are closed every month, every quarter and at the end of the year.

Beyond meeting a specific business objective, process benefits typically include improvement of: outcomes; accuracy; performance and quality. Processes also enable the use of tools and support effective training.

Robotic automation would certainly contribute to the benefits of performance, quality and accuracy, but there’s not indication that rules, as such, are a major factor in process composition. Processes have procedures and standards, but those can be subjective in nature – not clear, objective, rules.

Activities: An activity is scope of work, integral to realizing the business objectives of the process, beyond the capabilities of an individual. Activities often have preconditions which must be met before they can start. In our example, activities related to the closing of books of one month cannot begin until work associated with closing the prior month is completed. Activities require resources and have clearly defined completion outcomes – typically preconditions or dependencies for related downstream activities.  

Tasks: A task is a scope of work, typically within the capabilities of an individual but large enough to be within supervisory accountability. Associated tasks are normally grouped to form a discrete activity. In our example, a member of the accounting department may have the task of posting journal entries for a business unit into the trial balance. His task would be aggregated with others in a Posting activity.

Rules: it’s about Activities – not Processes

This high level decomposition serves the purpose of illustrating how misleading the term “rules-based processes” can be, particulary to those new to RPA and considering an implementation. As a practical matter, processes are simply a collection of activities, which in term are an aggregation of tasks.

Therefore, attempting to apply a robotic process automation criteria on the process level would be a mistake: rather, the activity level is where the relevant information is to be found. In our example, closing the monthly books consists of at least eight distinct activities. Some of those activities may be comprised of highly rules-based tasks while others may not.

Two essential data points can be determined by focusing at the activity level. One, of course, is the existence of rules-based work. The other is the the scope of rules-based work: the critical mass. If the scope of that work on an activity level is sufficient to meet an ROI criteria, then implementation of robotic process automation makes sense – regardless of whether or not the process itself is perceived as rules-based.