The hidden perils of process automation



“Shouldn’t this process just be automated?” It’s a common question that many business people run into at one point or another. For years, the business process management industry has been extolling the virtues of automating workflows. We’ve been habituated to think that just about everything can, and should, happen at “the click of a button,” or better yet, with no button click at all.

Thanks to process automation, you can now drive through toll stations at forty miles an hour instead of stopping to dig change out of your pocket for a churlish toll booth clerk. You can click “forgot password” on just about any website and get an email within seconds that contains a link to reset it. The single-button-click payoff is incredibly rewarding when everything goes as planned and expected, but it can also lead to some spectacular blunders:

  • In 2010, a computer algorithm went rogue at Credit Suisse Bank and accidentally traded 200,000 futures contracts to itself.  
  • The year before, lack of appropriate human oversight caused Bank of America to foreclose on a Naples, Florida couple who never even had a mortgage. That one, at least, ended in sweet, sweet justice: the couple fired back, foreclosing on their local Bank of America branch when it failed to cough up the court-ordered sum to cover their legal costs. The bank finally relented and produced a check when the sheriff started ordering bank tellers to surrender the money in their tills.
  • And let’s not forget famed comedienne Joan Rivers plugging for the iPhone 6 after she was already dead.

I’m certainly not saying that process automation is detrimental across the board; obviously it isn’t. I am saying that there are critical risk factors that should be considered before you decide to automate your process. Here are a few considerations that you should give significant thought to before you make the decision to automate.

How variable is the process you want to automate?

Is it a process that should be executed exactly the same way, every single time? The more variable the process, the more opportunities there are for automation to go awry and cause significant problems. It is certainly possible to automate a variable process, but computers are vastly inferior to human beings when it comes to exercising discretion and judgment. Computers deal in algorithmic rules, which means that if you can’t devise a hard-and-fast rule for exactly how the system should handle every scenario that might arise, there will be circumstances that the automated system isn’t capable of dealing with, or that it deals with inappropriately.

If, on the other hand, you feel pretty confident that you can identify and clearly describe all of the sources of variability that are likely to come up, then automation could be a practical solution, but be aware that the cost of automation in terms of up front development time and effort can increase exponentially if you have to program the system to handle variable workflows.

If you’re not sure how variable your process is, look to inputs and outputs. A process accepts certain inputs and uses them to perform a series of actions or steps that in turn produce a particular output.  The first source of variability is the inputs to the process. If yours is a business process that happens in they physical world (as opposed to the digital realm), the inputs to your process are probably three-dimensional in nature. They have mass and occupy a volume of space, and have other physical characteristics like density and weight. Automation would generally mean having a computer-enabled machine apply force or work to some set of physical inputs to produce something that is of greater value than the sum of its parts.

If you want to automate, you’ll generally have to provide your process with very consistent inputs to realize the efficiency gains you’d hoped for. To use an absurdly simple example, my food processor leaks all over the counter if I put more than a few ounces of liquid into it. But I’m prone to forgetting this fact, and it causes me problems when I blend tomatoes, which liquefy when blended. In similar fashion, my blender overheats when I don’t put enough liquid into it. I tend to forget that when I’m making blended lentil soup, which can become thick and viscous quite quickly. Both of these are examples of process automation tools that aren’t capable of handling input variability.

Computers are much the same way. The inputs they take in is digital rather than physical in nature, but the same problem tends to arise. Take, for example, malicious computer code. Malicious code such as viruses and worms are examples of a type of input that many computer systems aren’t capable of handling because they are unable to exercise judgment in the same way that a human being would.

A common method of handling this challenge in both physical and digital automation schemas is to scrub, sanitize, or norm the inputs that are fed into the system. This can be accomplished by causing the system to reject or ignore certain types of inputs, and also by that reliable old standby, human effort, the application of which diminishes the value proposition of automation in the first place. Returning to our earlier example, the company that makes my food processor expects me to remember not to pour liquid into it. This may be a viable approach for you, but ask yourself whether it’s workable to define only a very narrow type of inputs for your process to accept. How many valid or acceptable inputs might the system end up rejecting? Does that work for you? This can be a very loaded question if the process is customer-facing, because the customer generally ends up on either the input or the output end of the process equation, and sometimes both. And trust me, no one will appreciate being rejected, normed, scrubbed, or sanitized by your process.

At the other end of the spectrum, you can understand the variability of your process by looking to outputs. How narrowly can you define the output your process is supposed to create? Is there a clear, discrete, uniform definition of success? Ideally, in an automated system, there aren’t multiple definitions of a successful output, but most automated systems can handle multiple scenarios if programmed correctly.

If the process is expected to produce variable outputs, the automated system has to be programmed to execute different task flows depending on the circumstances of the situation. Ask yourself why the process is supposed to produce more than one type of output. If the process is supposed to accept uniform inputs but create variable outputs, how is the automated system supposed to know what type of output to produce? You’ll need to build in some sort of a mechanism that allows an operator or process manager to provide the automated system with the information it needs to understand what kinds of outputs it should generate, and when.

There is a single case in which I’ll advocate pretty strongly that a process probably should not be automated. And that situation exists when a broad array of variable inputs are fed into the process, and a broad array of variable outputs are expected to be produced as a result. This is often the result of highly variable external circumstances, human beings operating in an uncontrolled system (sometimes I like to call that “life”) and more than one possible definition of a successful outcome.

Here are some examples, just to make sure you’ve got your head wrapped around it. My best example is buying a new home. It’s a distinct process, for sure. Combine a buyer, a seller, and a source of financing, run them through a multi-step process that has several distinct workflows, and the outputs are a homeowner, a loan to be serviced, and person who has divested of property for compensation.

Buying a home is a process that can be systematized, and has been to a great degree, but I think it would be a terrible candidate for automation. Every buyer has a different set of criteria for the home they want to buy. Some want a condo in the city, others want farms, some might even want houseboats. Some buyers want a rental property, others want a house to grow old in. The process of buying a house has a rather routine set of workflows associated with it, but they differ from state to state, and in some places even from county to county. Everyone has a different idea of what a successful transaction looks like. Some buyers have a tight time frame and want to close quickly; others are willing to hold out for the perfect house.

Does this mean that Realtors should throw up their hands and abandon technology entirely? Not at all. Far from it. What you often see in these instances is a complex human-machine interaction in which the overarching process is effectively stewarded by a capable person, and the more routine elements of the process, which I’ll call “snippets” are automated by technology. Some examples of automated snippets are algorithmic tasks like the preparation of standardized forms and the drafting and transmission of electronic communication.

If you end up deciding that process automation might take you on a lengthy and unproductive journey, don’t worry. There is an alternative, and it’s called guided navigation. Guided navigation is the art of stewarding an individual through a process that is fundamentally human-centered in nature. A guided navigation system can walk a user step-by-step through any flow of work that requires the application of human discernment and judgment to be successful. If you haven’t guessed by now, Navitome’s buisness process guidance and training software does exactly that.


Before you decide to purchase a fully-featured business process management package and jump onto the business process automation bandwagon, take a second to think critically about the sources of variability that exist in your business processes. You might even make a list. Take stock. Turn off all the lights, spend some time in quiet reflection, and consider how much variability actually exists in the business process(es) you’d like to automate. Does it need to be there, or is the process only variable because it’s not carried out with any consistency? Accidental variability rarely provides value in business systems. Would it be expensive or impractical to try to reduce some of the variation? Would reducing the level of variability that your process is capable of handling also erode the value you create?

So before you automate, ask yourself, “Do I really want this to happen at the click of a button?” Expertise, empathy and judgment can’t be automated. And what’s more important, they shouldn’t be.

I’d love to hear from you in the comments below – what are some kinds of variability that you’ve had to deal with in your business? Did you try to automate in spite of them?


Submit a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>