We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Does automation hurt business process or help it?

Vote 0 Votes
An interesting question that Michael Poulin brings up on this LinkedIn topic, Is fully automated business process still Business Process: does automation hurt business process or does it help it?

13 Replies

| Add a Reply
  • In general, automation has proven to reduce error and increase throughput. Clearly, automation requires the appropriate level of monitoring and instrumentation to ensure that the process is operating as expected, but ensuring that a process is within range of it's KPIs is what makes it BPM.

  • It's kitsch to say it 'depends' but I think it is actually applicable here. If it is a lousy process to begin with, automating it may make things worse. I think the question always has to be asked up front: "Why am I automating this process, for what purpose? What problem am I solving by doing this?"

  • This is a really interesting question, even if it ultimately just boils down to how you define your terms.

    I think of two levels of automation of business processes. Level 1 is automating the selection of the activity that should happen next (call it the "flow"). Level 2 is automating individual activities. If you automate the flow and you automate all the activities, then a non-technical person is likely to say that it is no longer a business process. It's a program (to use a term that software people don't use much anymore). That isn't to say that it has any less value than when the steps were being done by people. In fact it likely has more value, it just isn't thought of as a business process.

    If only the flow has been automated and the activities are still mostly done by people then I'd say that it is still a business process in most people's eyes. Nonetheless, when a new line worker is hired and they are being taught the "processes and procedures" of the company, they are likely to be taught only about what they need to do, such as pull work off their worklist and perform their appropriate tasks. It is at the higher levels of management where there is visibility into the whole flow of work and therefore more thought of the automated process as a business process.

    This results in an interesting conclusion -- when you automate your business processes it means that fewer people have to learn about and understand the actual processes of the business, but those processes are more repeatable and there is more visibility by management into what the business is doing as it is happening.

  • Business process automation has the potential to both help and harm. The direction - positive or negative - automation takes will depend largely on the people who make the design decisions and implement the automation. As Chris alluded earlier, there is no point in automating a broken process. Fix it, then automate.

    Automation can be a genuine advantage for a business process that contains numerous routine activities. We can achieve efficiencies and consistency with results through automation.

    The challenge is that as a process becomes more automated there appears to be less understanding of how it actually works. When that understanding breaks down, business process improvement becomes far more difficult and costly.

  • I came in here to add a point, and part of which is already covered (very well) by Michael. So I won't venture elaborating again about the point about the automation of "all" v/s some activities. The objective for an efficient process is to get repeatable and consistent efficiency which you can achieve through automating a process that does what it's supposed to.

    However, there are two more distinct points that I want to make which I think people often confuse.

    One is that objective of Process Management is not Process Automation. Process Management is about ability to complete the full cycle of design, execution, monitoring and optimization in an iterative manner. While Automation is sometimes a way to get the consistent output from certain portions or whole process. So, even if I have automated the whole process, there's still the need to get visibility into various steps and participant systems and ensure the process is managed well in the life cycle that I just mentioned.

    Then, there's a point about "Automation" as a term itself. Automating the process (or steps of process) is different from automation of the process execution. BPMS definitely enables a better process lifecycle management by providing the ability to "execute what is designed" and "monitor what is executed". So, this bit of Process Execution Automation has been a great thing for Process Management. While the other bit of "Process Automation" depends on whether the underlying process was accurate in the first place, and whether people doing it assumed it to be the end-goal of the process management.

    - Ashish

  • If by ‘automating’ you mean taking portions of a process that were once performed by a person and using business rules, event processing, and other logic to make these activities performed by the BPM engine or external application, then no, automation definitely does not hurt BPM.

    In our experience a successful process analysis exercise and/or BPM deployment will always automate various components of the process. This is a key component in wringing value out of the process – reducing errors, improving throughput, etc. Successful BPM methodologies use simulation and analysis to identify areas of a process that are ripe for automation.

    Our approach to BPM would look for opportunities for automation in any process, even in process patterns like case management that can be largely non-deterministic.

    We have helped organizations deploy case management processes where the gathering of background data (i.e. requesting information from a variety of sources and then aggregating), generation of hardcopy output, case “configuration,? etc. were all manual, multi-system activities that we were able to successfully automate.

  • Obviously: anything that can be automated, should be. Which processes can be automated? Those which are repeatable enough that the cumulative benefit out weighs the cost of implementation.

    Nobody is going to disagree with the above, but the big problem is that processes often appear more repeatable than they are. I touched upon this briefly in a blog post: Structure is in the Eye of the Beholder. This leads some people to attempt automation when not justified, and they don't find out until they start to use it.

    When one attempts to automate a process which is not repeatable enough, the result is usually that people simply don't use the provided application. They go around it. So there is no real harm except the lost investment in development. I can't really think of any cases where automation "hurts a process".


  • Automation helps a business process massively if used correctly for the right steps for the right processes. Automation increases throughput reduces error rates, raises efficiency and saves on process costs.

    However, all too often automation is used for steps and processes that really cannot be truely automated. In these cases it can hurt a business process and ultimately the business full stop...

    Like most things in BPM, the key is knowing when to use the tools at your disposal

  • I think everyone has said all the important points on this - I want to try saying this a little differently.

    Many activities may be repeatable, however, there are activities of the process, where Judgment, decisions, deductive analysis etc. are key to execution. These have to be protected when you automate a process. If you overlook these, you will have a great automation, but are probably off mark when you look at process results.

    Those are the typical situations where one might say automation has hurt business process.

  • In the short term automation helps, but in the long term I'm skeptical about automation.
    Referring my own post, "Most cases, we standardize processes to increase quality and productivity, meaning that we make processes as routine and repeatable as possible.", hence automation does help, in the short term, I believe.
    But at the same time, business processes contain certain business decisions and criteria to make those processes work as portions of businesses. In the long term, by automation, those business ingredients likely be forgotten.

  • In my experience automation itself does not hurt. What hurts is not understanding the needs of the business processes (in other words, lousy process) subject to automation. This leads to situations mentioned above: business decisions and criteria hardcoded (and effectively lost) in automation routines. Or missing support for some judgment, decisions, deductive analysis etc., which leads to inflexible processes that are eventually abandoned.

    A few posts mention that automation leads to less understanding how processes actually work. In my experience, I saw the opposite effect: Due to analysis and process models leading to automation, the organization actually was gaining insights into its own processes. At least this was the case with initially lousy processes.

  • In applying automation to business processes, I think, we should not repeat already known problems with automation of human work. In short: It does not mean that the goal is to replace humans by programs. On the contrary, the human is in command as he/she is responsible for the outcome. Any automation is to help the humans to carry out their work.

    In long: a ten years old “Pitfalls of automation? reproduced at http://improving-bpm-systems.blogspot.com/2011/01/automation-and-intelligent-systems.html


  • What would really help is not to automate the processes. It's to automate the way in which the applications supporting such processes are developed.
    This enables consistency between process models and their implementations, quick prototyping and user feedback collection, and immediate adaptation of sw to process changes.

Add a Reply

Recently Commented On

Monthly Archives