Harmon on BPM: The Varieties of Process Change

I read two process-related articles recently, one enthusiastic about Robotic Process Automation (RPA) and the other arguing that Process Mining was the wave of the future. Now it happens that I am interested in both of these process technologies, and would suggest to any company team that they explore them. On the other hand, I don't think either is going to entirely revise how we think of business process change. To explain my skepticism, let's step back and think, broadly, about some of the challenges the process professionals face.

In many cases, processes already exist. Your company has been taking and entering orders for years. You have a well-defined procedure for logging the orders, reviewing them, accepting payment, and passing the items and the order forms on shipping to be fulfilled.

Unfortunately, as this process was created before your organizations recent growth, it was designed to be done by clerks, by hand, and has little computer support, although the actual sales are recorded in the customer database.

So, can we do process mining? Probably not. Process mining requires access to computer data that allows it to track each step in a process. In this case, the order is placed over a counter, hand documented, and only appears as data when a payment is made and a customer data entry is made. From a data perspective, there is no process, only an event.

In a similar way, could we use RPA? No again. RPA allows us to automate moving data from one software application to another. It eliminates a clerical task which had previously required that a clerk copy data from one computer system and enter it into another. A quick glance at our sales procedure suggests no tasks of this kind to eliminate, hence, no use for RPA.

Let's assume your organization decided to do some automation. The process we just described is automated with a website that captures each entry any visitor makes. Could we use process mining now? Well, not right away, because we simply wouldn't have enough data, but after a while, once data had accumulated, we could use data mining to capture the flow of activities on the website and see how the typical customer moved through the steps available. We could find points at which customers often stopped and left the website, and we could examine to see what seemed to frustrate and ultimately send customers away. We could look for bottlenecks and identify places were customers took a long time and we could see if we could improve instructions, or available information, to make it easier for customers to proceed more quickly.

How about RPA? Since we don't transfer any information by hand, but have the whole process automated by the website software, there's really no use for RPA.

Now let's consider a different situation. Imagine that your company had begun a serious automation push several years ago. It had introduced a website that allowed online customers to choose from a catalog and use credit to purchase items online. As website options are used, the website sends information to a database, and, ultimately, a fulfillment system that generates shipping documentation and the orders are shipped. A clerk checks the system on a daily basis and transfers information about the new purchases to the customer database, which isn't linked to the web system because they were developed at different times, using different software and would be hard to link.

What about data mining in this case? As with the example above, we could use data mining and we could use it right away – we have lots of data on the moves users make as they use the website. The data would let us examine flow patterns, and we could use those patterns to identify places we might intervene to improve the process.

What about RPA? As data is transferred from the website to a customer database by hand, it's likely we could use RPA to automate the link and eliminate a tedious task that is now being performed by humans.

Finally, imagine that you are asked to design and implement a new process to allow customers to get information about your company via their smart phones. You need to imagine what would trigger the use of the process, how it would work, and how you could make the steps easy and fun for the potential users. Could you use either data mining or RPA? No, both of those techniques are only appropriate for existing processes, either a process with accumulated data, or a process in which there are disconnects between software systems.

I've been a bit pedantic here, but I want to emphasize that, in spite of promotional campaigns that seem to suggest that Process Mining or RPA will revolutionize process improvement, they won't. They are valuable tools, like many others, and they should be considered when they are appropriate, but they are limited tools, like most others. Builders don't use hammers to screw in screws. Process practitioners shouldn't use tools designed to improve existing processes to try to build new processes, or to improve processes that don't have the characteristics required by the technology.

Business process change involves many different types of activities. We analyze organizations to determine how all the various processes work together to generate value. We analyze value chains to see which major processes contribute the most to the bottom-line. We redesign existing processes, to improve human performance, or to automate tasks that can be automated. In some cases automation involves the use of machines and in other cases it involves the use of computers and software. We create new processes to take advantage of new technologies, or to get into new lines of business. We have dozens of tools, from software apps to intellectual rules of thumb that help us in our work. Learning the tools in the toolkit, and learning when to use which tool is a major part of becoming a skilled process practitioner.

PDF Version

Bio
Latest Posts

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 BPTrends Associates, 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 Las Vegas. Paul can be reached at pharmon@bptrends.com