Harmon on BPM: Robotic Process Automation Comes of Age

The history of “business rules” is rather meandering but interesting. There are really two roots to the field. One lies in Expert Systems – the popular manifestation of Artificial Intelligence (AI) that was popular in the Eighties. Expert Systems were created by defining the rules that human experts used when they solved problems. Those rules were then placed in “expert system-building software tools” which added an inferencing algorithm that could examine the rules and use them to solve problems. By the end of the Eighties interest in Expert Systems waned because it proved too expensive to maintain the Expert Systems, once they were built. Human experts keep learning: They go to conferences and read books and they keep updating their rules as new knowledge becomes available. To update an Expert System, one needed to go through the rule base and revise rules – something that proved very time consuming. The expert system software tool vendors were at a loss for a while, several simply went bankrupt, and some survived by repositioning themselves as “business rule tool vendors.”

The other root of the business rules movement lie with database vendors. In the Eighties, relational databases were being challenged by other types of database vendors, who stressed that relational databases could only store programs, but couldn't store the logic used to manipulate that data. To counter that objection, major database vendors and users developed ways of storing rules that captured business logic within relational databases. The emphasis on storing business logic as rules led some to suggest that organizations ought to set up groups that would focus on capturing business logic in standardized rule formats.

In 1989 several people came together to form the Business Rules Group (www.businessrulesgroup.org) which proceeded to promote the idea that organizations ought to capture and save their business rules. This approach has proved especially popular among organizations that rely on rules, including financial organizations and government agencies.

In the new millennium, business rules groups discovered expert system tool vendors, and a new generation of business rule tools were developed to allow organizations to create applications that could examine rules and reach conclusions. This made business rules even more useful and popular among some users. The Object Management Group (OMG), a major standards organization made all this even more popular when it issued several business rule standards, some based on the earlier work of the Business Rules Group. As interest in capturing business rules grew, the former expert system tool vendors repositioned their tools to be business rule management tools. Unlike expert systems that dealt with very large rule sets and rules derived from interviews with human experts, the new business rule tools were reshaped to deal with smaller, simpler rule sets derived from clear policy statements.

The growing interest in Business Process Management during this same period led to a off-and-on marriage between business rules advocates and process people. From a process perspective, business rules simply defined the way decision makers approach decisions that occurred within certain activities. Defining rules became a type of analysis that could be used to better analyze complex business processes. Once again, some of the rule tool vendors mutated into BPM tool vendors and other rule tools were acquired by leading BPM tool vendors to enhance their process management software offerings. This pretty much described the state of “business rules” a couple of years ago.

Recently a new twist has been introduced – Robot Process Automation (RPA). This term is misleading, since “Robot” suggests the use of AI or cognitive techniques, which are popular at the moment. In fact, RPA has little to do with the current surge of interest in cognitive techniques. Like BPM, RPA tools “sit on top” of existing software applications and allow developers to “automate” links between programs,. In the simplest case, one would simply say “take the result that appears in box 35 of application A and insert it in box 2 of application B.” In more complex cases, one would write a set of rules to explain how to modify the initial data, or how to route it, depending on the nature of initial data. Thus, if a human currently finds that they are routinely copying data from one application and entering it in another (e.g. acting in a robotic manner), then RPA tool will let an individual write a bit of script or use a graphic interface to show that data from one application is to be transferred and entered in another application. If there are branching options involved, then rules can be added to specify more complex manipulations.

RPA is being promoted as a real breakthrough, but lets consider what's really involved. First, RPA is being proposed to allow an organization to sew together outputs from one application with needed inputs to another application. In an ideal world a new and more comprehensive application would be written – but in this world, “duck tape” will work well enough and can be applied much faster. Vendors have argued that department personnel can use RPA, thus avoiding waiting in line for IT to develop a fix. I wish I had a dollar for every new type of software tool that made this claim over the course of the past couple of decades. It was the major selling point for BPMS tools, and proved completely illusionary.

As with BPMS and CASE and Expert Systems, there are undoubtedly some simple situations that will yield to non-programmer uses of RPA. As RPA is used, however, and applied to more complex situations, don't be surprised if you find that you need someone with a programming background to develop the scripting language. Even a few rules, carelessly written, can introduce some strange loops.

RPA seems to me a scaled down version of BPMS, just as the use of rule software tools to handle “business rules” was a scaled down use of expert systems-building tools. Perhaps this time the rule vendors have found the sweet spot, and come up with a use of business rules that ordinary business people really can use.

At the moment there are a number of new vendors offering tools to do RPA. Predictably, as interest grows, the leading BPMS vendors will all offer their own versions of tools to do RPA or simply acquire an existing RPA vendor.

We all know of situations where we take data from one application and then immediately turn and enter it into another application. I was just at the local Department of Motor Vehicles and watched with a kind of bored horror as a clerk painfully copied information from my previous drivers license, on screen, to an application form, also on screen, for a renewed drivers license. I wondered if she did a hundred of these transfers a day, what the odds were that she wouldn't make at least one or more copying errors.

If business analysts can use RPA to automate several of these “transfer” operations, surely it will save employees lots of time and significantly reduce errors.

From a process analyst's perspective, this is a way to deal with problems that arise when employees are forced to routinely work with two or more existing software applications, transferring data between them. If this shows up when you examine a process, RPA is a solution to consider.

Paul Harmon

Paul Harmon

Executive Editor and Founder, Business Process Trends In addition to his role as Executive Editor and Founder of Business Process Trends, Paul Harmon is Chief Consultant and Founder of Enterprise Alignment, a professional services company providing educational and consulting services to managers interested in understanding and implementing business process change. Paul is a noted consultant, author and analyst concerned with applying new technologies to real-world business problems. He is the author of Business Process Change: A Manager's Guide to Improving, Redesigning, and Automating Processes (2003). He has previously co-authored Developing E-business Systems and Architectures (2001), Understanding UML (1998), and Intelligent Software Systems Development (1993). Mr. Harmon has served as a senior consultant and head of Cutter Consortium's Distributed Architecture practice. Between 1985 and 2000 Mr. Harmon wrote Cutter newsletters, including Expert Systems Strategies, CASE Strategies, and Component Development Strategies. Paul has worked on major process redesign projects with Bank of America, Wells Fargo, Security Pacific, Prudential, and Citibank, among others. He is a member of ISPI and a Certified Performance Technologist. Paul is a widely respected keynote speaker and has developed and delivered workshops and seminars on a wide variety of topics to conferences and major corporations through out the world. Paul lives in San Francisco. Paul can be reached at pharmon@bptrends.com
Share

Comments

  1. Claude Patou says:

    At each new tool : new businesses, new customers, new thoughts, new concepts : new vision. It’s life. You take it or you fall because all others take it.
    Lets people thinks, more they wait more they lost ¥-€-$ & £.

  2. So far, of the people responding to our mini-survey, about half haven’t heard of RPA and the other half are exploring it. Please tell us what your organization is doing with RPA.

Speak Your Mind

*

Share
Share